Timeline for Should I report a security vulnerability?
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 9:49 | history | edited | CommunityBot |
Commonmark migration
|
|
| Nov 12, 2019 at 16:57 | comment | added | Conor Mancone | @jdgregson Now that you mention it, CVV was probably a typo. I heard CVSS, while you obviously heard CVE. Both are good guesses... | |
| Nov 12, 2019 at 16:15 | comment | added | jpaugh | @jdgregson You mean every common vulnerability has its own CVE? I thought those only applied to specific bugs of specific software. There are any number of ways to incorrectly build & deploy a website (which I would expect a scanner to catch); but I'm surprised to hear that all of those would also have CVEs. | |
| Nov 12, 2019 at 6:27 | comment | added | jdgregson | @jpaugh I think in this context we're talking about known vulns which happen to be CVE 10. For example, finding a server still vulnerable to Heartbleed. A scanner wouldn't be scanning for -1-days to begin with. | |
| Nov 11, 2019 at 23:48 | comment | added | jpaugh | @jdgregson A CVE is not something that a "skiddie" would have access to. From what I've heard, you basically have to know the right someone in order to get a new CVE assigned to a vulnerability once you've discovered it. | |
| Nov 11, 2019 at 17:15 | comment | added | jdgregson | I'd question the competency of any security team which disregards reports of public-facing 10.0 CVEs just because the reporter is "some skiddie using a scanner". | |
| Nov 11, 2019 at 13:13 | comment | added | Conor Mancone | @jpaugh I already had mention of that in my answer, although obviously it wasn't obvious enough. I've put up a small update accordingly. | |
| Nov 11, 2019 at 13:13 | history | edited | Conor Mancone | CC BY-SA 4.0 |
added 242 characters in body
|
| Nov 10, 2019 at 23:33 | comment | added | jpaugh | @ConorMancone Please include your last comment in the body of the question, because it's relevant: the question implies that the OP has not contacted the company, and therefore does not have permission. | |
| Nov 10, 2019 at 20:24 | comment | added | Voo | @Conor Fair point, if it's purely from that PoV that makes sense. | |
| Nov 10, 2019 at 20:20 | comment | added | Conor Mancone | @Voo my answer is really just approaching this from the perspective of activity with permission or under a bug bounty. As I mention in my answer, scanning websites without permission is illegal, so obviously the OP wasn't asking about that. If someone was scanning illegally then the only advice I have is to stop doing that. | |
| Nov 10, 2019 at 20:07 | comment | added | Transistor | @user1067003: Please refrain from coarse language on SE. It demeans all of us and it's totally unnecessary. | |
| Nov 10, 2019 at 13:58 | comment | added | Voo | @Conor But the premise here is to only contact the people after verifying there's no FP. Sure if you have a bug bounty program or permission (and really if you have neither you should never have scanned them in the first place, which makes this point moot) it's simpler, but then I'd think that generally involves contacting someone. But say you get back that there's probably a vulnerable version of Apache installed - how do you figure out whether that's correct or not without trying a vulnerability? (The server might just be configured to send any old information back after all) | |
| Nov 10, 2019 at 13:45 | comment | added | Conor Mancone | @Voo that's not usually too big of a problem. Presuming that you are working with permission or under an established bug bounty program, the extra steps required to verify the report wouldn't be considered hacking and are just part of the job. Also, many times the false positives are easy to verify as such with little extra effort. | |
| Nov 10, 2019 at 13:35 | comment | added | Voo | "verify that the scanner isn't reporting a false positive [..] shouldn't "hack" into the system". Not saying it's impossible to verify without breaking into the system, but in many situations that doesn't seem easy to do. | |
| Nov 10, 2019 at 12:45 | comment | added | Conor Mancone | It is true that current laws make it dangerously easy for misunderstandings to lead to criminal charges for legitimate security researchers that were just trying to help. It would be great to fix that. But being able to perform active penetration testing on sites without permission is not a reasonable solution. | |
| Nov 10, 2019 at 12:44 | comment | added | Conor Mancone | @user1067003 I don't really agree. Expecting to scan sites without permission would be like walking down the street trying to open people's front doors. Then when someone calls the police and they show up you reply with, "I'm just checking to make sure that people locked their doors" and expecting the police to be happy with it. It's a terrible idea. | |
| Nov 9, 2019 at 14:13 | history | edited | Conor Mancone | CC BY-SA 4.0 |
deleted 1 character in body
|
| Nov 8, 2019 at 18:35 | comment | added | Conor Mancone | @MikeOunsworth I went ahead and updated my question to better emphasize my actual suggestion, which is sending a detailed vulnerability report instead of a report from the scanner. Although in doing so the organization of my answer now more closely mirrors yours. :shrug: | |
| Nov 8, 2019 at 18:34 | history | edited | Conor Mancone | CC BY-SA 4.0 |
added 465 characters in body
|
| Nov 8, 2019 at 18:15 | comment | added | Mike Ounsworth | I'm one of the security team members who receives random reports like this. I agree that 90% of the time it's a false positive sent by an amature sec researcher who has no idea what the finding means. That said, 10% of the time, it's a tool we don't run and it's useful. Also, 100% of the time it tells us about the PR impact of people scanning our site. We do sometimes make "unnecessary" code changes purely for PR reasons so that our customers get less alarmed when they run a scan. | |
| Nov 8, 2019 at 17:51 | history | answered | Conor Mancone | CC BY-SA 4.0 |