3 ms·

Not sure what exactly that changes. It's still a relatively basic vulnerability and they still school the reporter after changing ("clarifying") their policy [0

Not sure what exactly that changes. It's still a relatively basic vulnerability and they still school the reporter after changing ("clarifying") their policy [0]. I realize it's worded to not come across as a threat but I'm not sure why that was necessary either. It might have been out of scope according to some H1 guideline the reporter wasn't aware of but what the reporter did wasn't really out of the ordinary. https://hackerone.com/security/policy_versions?change=3624684 https://hackerone.com/security/policy_versions?change=362468...

shkkmo 7y ago
> Not sure what exactly that changes. Tone and how you treat your reporters matters. The comment quoted by the person I responded to was edited to include this after they read the full report: >> Edit: This comment was based on an incomplete understanding of the specifics of the communication between H1 and the reporter. This assessment wasn't the most fair, and I probably should have read the full report before passing judgment. [0] You say: >I'm not sure why that was necessary either. It might have been out of scope according to some H1 guideline the reporter wasn't aware of but what the reporter did wasn't really out of the ordinary. Isn't it exactly the commonness of that practice that makes it clear it is important to take the time to educate your reporters and improve your policy? The amount of sensitive data was accessed increased the severity of the breach. HackerOne specifically acknowledges this as one of their planned courses of action to improve things going forward: >> As the community grows, HackerOne needs to ensure that HackerOne is reinforcing the best practices in bug bounty hunting. The HackerOne Community team will look to increase hacker education around delivering proof of critical severity vulnerabilities in case sensitive information has been accessed by the hacker. [0] https://arstechnica.com/information-technology/2019/12/hackerone-breach-lets-outside-hacker-read-customers-private-bug-reports/?comments=1&post=38352571#comment-38352571 https://arstechnica.com/information-technology/2019/12/hacke...
- tastroder 7y ago
  Fair enough. I find it rather patronizing but I also kind of get your point. H1's gamification requires them to educate their users to some degree, sure. Although I find that far more problematic than some common practice. I'd prefer policy that reflects reality. "If you see usernames or reports, stop and report it" might help with the part of the user base that bought into the gamification but I'm really not sure how that helps responsible disclosure in general. If you're not a paid external security researcherm, of course you click on at least one report to confirm that the vulnerability is actually working and has meaningful impact. Plus, they're still working with curious humans here, not OWASP top 10 scanners. That's just like all those bug bounty programs including some phrase disallowing automated tools. Even for active participants of the platform that's completely unrealistic and introduces unnecessary uncertainty.
  - thaumasiotes 7y ago
    > That's just like all those bug bounty programs including some phrase disallowing automated tools. Even for active participants of the platform that's completely unrealistic and introduces unnecessary uncertainty. I was a report triager on HackerOne for over a year. There is a good reason for that clause, and I would definitely recommend any program that didn't already have it (which is only programs new to bug bounties) to adopt it. What's disallowed is filing a report consisting of the output of an automated tool. Look at Uber's scope statement ( https://hackerone.com/uber https://hackerone.com/uber ): > Out-of-Scope >> Negligible security impact >>> Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue >>> Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated This prevents a denial-of-service attack on Uber's bug bounty team. It's very, very common for someone to run an automated tool against one of your domains, copy the output into a HackerOne report, and walk away. In nearly all cases, that output is a scary-looking false positive. It doesn't make sense to investigate reports like this, because they are almost always spurious -- so they are placed out of scope. If you file a report consisting solely of automated output, your report will be closed without investigation per the company's policy. The only problem being addressed by the clause is that reports like this are a waste of our valuable time. Automated tools themselves are not disallowed. (How would we know?) The requirement is that you investigate the bug yourself, and provide a writeup that indicates that you did so and substantiated that there really was a security issue. > If you're not a paid external security researcher, of course you click on at least one report to confirm that the vulnerability is actually working and has meaningful impact. Plus, they're still working with curious humans here, not OWASP top 10 scanners. I have a lot more sympathy for you here. I have personally seen the same company pay out thousands of dollars more for the same security issue just because one of the reports alleged a bigger potential problem. (In this case, "you might be able to write to the database" as opposed to "you can read from the database".) This makes it hard for me to recommend "stop as soon as you know an issue is present", even though that is definitely the preferred policy of the companies.
    - tastroder 7y ago
      First off, I have to admit to a bit of snark when writing that up yesterday tbh and completely forgot about folks reporting some Nessus output etc. I'm absolutely with you when it comes to that type of automated tool and reporting, thanks for separating that. The Uber one is actually a great example of wording I can appreciate. I was thinking of one like Verizon Media's ( https://hackerone.com/verizonmedia https://hackerone.com/verizonmedia ). > Do not use automated scanners/tools - these tools include payloads that could trigger state changes or damage production systems and/or data. Unlike Uber's that's just a blanket statement and while I'm sure nobody wants to use it in that way (I actually like H1 acting as proxies for that alone, they surely mean something very similar to the example you posted), it's unrealistic and could make pretty much any attack ineligible. All that being said, at least the change to H1s own policy let's people know where they draw the line. Maybe I should change my mind, not every program has to be relevant to everybody at the end of the day.
staticassertion 7y ago
Most bounty reports that I've seen end up as teaching opportunities around how to make more effective reports in the future, and it isn't considered "schooling" them.

shkkmo 7y ago

> Not sure what exactly that changes. Tone and how you treat your reporters matters. The comment quoted by the person I responded to was edited to include this after they read the full report: >> Edit: This comment was based on an incomplete understanding of the specifics of the communication between H1 and the reporter. This assessment wasn't the most fair, and I probably should have read the full report before passing judgment. [0] You say: >I'm not sure why that was necessary either. It might have been out of scope according to some H1 guideline the reporter wasn't aware of but what the reporter did wasn't really out of the ordinary. Isn't it exactly the commonness of that practice that makes it clear it is important to take the time to educate your reporters and improve your policy? The amount of sensitive data was accessed increased the severity of the breach. HackerOne specifically acknowledges this as one of their planned courses of action to improve things going forward: >> As the community grows, HackerOne needs to ensure that HackerOne is reinforcing the best practices in bug bounty hunting. The HackerOne Community team will look to increase hacker education around delivering proof of critical severity vulnerabilities in case sensitive information has been accessed by the hacker. [0] https://arstechnica.com/information-technology/2019/12/hackerone-breach-lets-outside-hacker-read-customers-private-bug-reports/?comments=1&post=38352571#comment-38352571 https://arstechnica.com/information-technology/2019/12/hacke...

tastroder 7y ago
Fair enough. I find it rather patronizing but I also kind of get your point. H1's gamification requires them to educate their users to some degree, sure. Although I find that far more problematic than some common practice. I'd prefer policy that reflects reality. "If you see usernames or reports, stop and report it" might help with the part of the user base that bought into the gamification but I'm really not sure how that helps responsible disclosure in general. If you're not a paid external security researcherm, of course you click on at least one report to confirm that the vulnerability is actually working and has meaningful impact. Plus, they're still working with curious humans here, not OWASP top 10 scanners. That's just like all those bug bounty programs including some phrase disallowing automated tools. Even for active participants of the platform that's completely unrealistic and introduces unnecessary uncertainty.
- thaumasiotes 7y ago
  > That's just like all those bug bounty programs including some phrase disallowing automated tools. Even for active participants of the platform that's completely unrealistic and introduces unnecessary uncertainty. I was a report triager on HackerOne for over a year. There is a good reason for that clause, and I would definitely recommend any program that didn't already have it (which is only programs new to bug bounties) to adopt it. What's disallowed is filing a report consisting of the output of an automated tool. Look at Uber's scope statement ( https://hackerone.com/uber https://hackerone.com/uber ): > Out-of-Scope >> Negligible security impact >>> Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue >>> Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated This prevents a denial-of-service attack on Uber's bug bounty team. It's very, very common for someone to run an automated tool against one of your domains, copy the output into a HackerOne report, and walk away. In nearly all cases, that output is a scary-looking false positive. It doesn't make sense to investigate reports like this, because they are almost always spurious -- so they are placed out of scope. If you file a report consisting solely of automated output, your report will be closed without investigation per the company's policy. The only problem being addressed by the clause is that reports like this are a waste of our valuable time. Automated tools themselves are not disallowed. (How would we know?) The requirement is that you investigate the bug yourself, and provide a writeup that indicates that you did so and substantiated that there really was a security issue. > If you're not a paid external security researcher, of course you click on at least one report to confirm that the vulnerability is actually working and has meaningful impact. Plus, they're still working with curious humans here, not OWASP top 10 scanners. I have a lot more sympathy for you here. I have personally seen the same company pay out thousands of dollars more for the same security issue just because one of the reports alleged a bigger potential problem. (In this case, "you might be able to write to the database" as opposed to "you can read from the database".) This makes it hard for me to recommend "stop as soon as you know an issue is present", even though that is definitely the preferred policy of the companies.
  - tastroder 7y ago
    First off, I have to admit to a bit of snark when writing that up yesterday tbh and completely forgot about folks reporting some Nessus output etc. I'm absolutely with you when it comes to that type of automated tool and reporting, thanks for separating that. The Uber one is actually a great example of wording I can appreciate. I was thinking of one like Verizon Media's ( https://hackerone.com/verizonmedia https://hackerone.com/verizonmedia ). > Do not use automated scanners/tools - these tools include payloads that could trigger state changes or damage production systems and/or data. Unlike Uber's that's just a blanket statement and while I'm sure nobody wants to use it in that way (I actually like H1 acting as proxies for that alone, they surely mean something very similar to the example you posted), it's unrealistic and could make pretty much any attack ineligible. All that being said, at least the change to H1s own policy let's people know where they draw the line. Maybe I should change my mind, not every program has to be relevant to everybody at the end of the day.

staticassertion 7y ago

Most bounty reports that I've seen end up as teaching opportunities around how to make more effective reports in the future, and it isn't considered "schooling" them.