How bug bounty firms kill security
Eitan Caspi
An Information Security leader and expert, for more than 25 years, living by the motto of ever improving. *** Open to relocation *** (expressed views are my own and not of my employer or clients)
This is soooooo dumb!! I hate it. This is one of the reasons attacker succeed so well today. It is VERY common at bug bounty firms, and a huge mistake in my view.
See at the bottom a standard reply I received today form a #bugbounty firm, Bugcrowd (but I have seen the same also many times for HackerOne), after submitting a low risk finding, about the fact that some settings sub-pages are accessible directly after a regular login (including the ability to change some of them), while by the UI flow - any access to the whole "settings" section - prompts the user for an extra OTP authentication, even after regular login, when the user is user-passwor authenticated).
I agree this is nothing scary, but security is built upon layers of exploitations, and any of the first steps can be something small like the above, that if it will be fixed at this level - all the attack chain would not succeed.
Asking researchers to submit reports only if they achieve a real life full impact - is a "double or nothing" attitude that omits a huge intermediate layers in the kill chain, while the researcher doesn't even know if her/his tremendous amount of efforts to the reach the "double" status (if this level of finding is found at all) - will be paid at all or if paid - will it be a fair in comparison for the efforts.
And what if the low finding that was rejected will not be addressed and an attacker will come across it and the attacker will be the one being able to find a way to create an impact (negative, of course) against the company? An impact that would have not being able to be realized if the reported issue would have been addressed by the company?
Refusing to accept such reports is harming on several levels:
1. The customer doesn't get the report, so it is not aware of a possible risk that can possibly be fixed easily and fast
2. If the customer does get the report - then it is unfair towards the reporter (a kind of a steal, actually)
领英推荐
3. The reporter's efforts and good will are denied (and nevermind the money, it is not the main point here) and push her/him away from submitting future similar reports, hence killing possible future discoveries and mitigations
My view is that we should encourage and reward any report that helps us improve our information security stand, at any level. Many times the low findings are the ones at the starting point of the kill chain, and they are mostly easy and fast to fix, hence let us achieve better security with much less resources. Stating in our actions that we only wish to receive the "sexy" and big stuff - is a deadly approach for cybersecurity.
The response I received:
"
After reviewing your report, we were unable to identify any security impact. As such, this has been marked as Not Applicable.
Unfortunately, there is no security concern with the current provided proof of exploit, therefore, unless further proof of impact can be provided the finding will be marked accordingly.
In order to be a triaged issue a submission must demonstrate an impact that can have an effect on the customer, the application/website, or its users. Submissions should always answer the question, "as an attacker I could", with a suitable demonstration of such. Findings that reveal points of information or security best practices without an impact are not eligible for a reward and should be explored further in order to demonstrate risk. When you are able to demonstrate this, please do so in a new submission. We look forward to your future submissions.
"
#vulnerability #securityresearch #bugcrowd #hackerone
CEO and security engineer
6 个月???? ??? ?? ?? ?????? ??????? ??? ???? ???? ????? ???? ?????? ???: https://chat.whatsapp.com/HWWA9nLQYhW9DH97x227hJ