> Not only are they reporting trivial issues, but they also aren’t testing our site in a respectful fashion, by doing stuff like signing up to real events with fake profiles.
2nd to last paragraph mentioned this which seems like the real issue behind this whole article. Receiving a couple of security emails a day isn't a problem but the fake activity sounds like it's bad for regular users.
No idea how to stop something like this though, maybe put up a page for bounty hunters with some clear guidelines on how they're expected to act?
You're pretty much doing everything right. You have a respectful disclosure page. It tells people not to disrupt the service. You could, if bogus signups are annoying you, set up a crappy staging instance of your app and direct testers there.
I might further:
* Fix the disclosure page so that it doesn't reserve thanks for people who find "high or critical" vulnerabilities. Sev:medium in security-researcher-land is XSS and CSRF, both of which probably merit thank-yous. I'd just thank publicly anyone who sends you a valid issue.
* Post to Twitter (under a DoorkeeperSecurity alias) the SHA1 hashes of the titles of disclosed vulnerabilities, so you can "notarize" findings and settle grievances about who found what first.
* Go ahead and live with people sending you annoying security reports. People will do much worse things to you than that over the coming years. If your service does well, eventually people are going to stop "warning" you about DoS-susceptibility, and just start blackmailing you about DoS attacks.
But otherwise, I'm not sure I see the downside here. The alternative, of course, is for people to find flaws on your site and then write up hysterical blog posts about it. Think of the annoyance you're dealing with as a small payment in exchange for (some) control over the security story of your site.
I'm frustrated because adding this page made us a target whereas we weren't one before. I agree we would have eventually become a target regardless, but hopefully this would be because we have a well-known product.
Bug bounties are not fun to manage. If it's any consolation, you should take heart in the fact that they are a pain in the ass for everyone running them. Everyone submitting is rude. Every "vulnerability" is a critical one. They all urge you to "please fix this right away." Prepare to get nmap scan reports that are piped over smtp.
I encourage you to harden your heart. A reward/recognition page is a small price to pay for avoiding an embarassing compromise.
If you really want to quash the general issue, pay some 3rd party to do some real csrf/xss/sql injection pen testing against your sight at the cadence that is appropriate for your dev cycle. If you move slow and deliberately, annual or semi-annual assessments can help you intercept the disclosures. If you're more agile, you'll need to consider something more embedded in your life cycle.
A few other thoughts:
1) Develop your copy pasta for your accept, reject and duplicate submissions. Write in a firm but appreciative tone.
2) For email from anklebiting submitters, refer to your policy. Your policy should say whatever you need it to say. If people want to dispute things, always express appreciation for their effort, but point to "the policy" as the reason things can't be the way they want them.
3) prepare for crazy people. Vuln reward/recognition programs really seem to bring out the old school bbs conspiracy theorists.
Thanks. I wasn't thinking that I was setting up a bug bounty program when I created the page, I just wanted to thank people who had helped us so far. I didn't realise what I was getting myself into, so I felt a bit over my head. But you're right there are ways we can make things go smoother.
If you aren't paying or updating your list of contributors, then I will just email Full-Disclosure, which also doesn't pay but functions as a permanent record of those who meaningfully contribute to security.
I'm responsible for information security at one of the other startups listed on BugSheet. As a heads-up, you're going to want to ask bugcrowd.com to remove your company from their list [1], also. We saw a pretty steep increase in the number of daily reports when first listed (4-5/day to >30/day) and it appears someone recently added your company to their site.
I'll also echo what droopybuns stated - creating templates that can address preliminary communication (duplicates, request more info, accept, etc.) will greatly reduce the amount of time you feel as though you are wasting. Some people I know tend to ignore the crazy ones but I generally prefer the "kill them with kindness" approach. One email explaining that you do appreciate the time they spent trying to help secure your site can do a lot to prevent harassment and potential bad press.
Best of luck - responsible disclosure programs are never fun for the person sifting through the reports but once in a while they do expose actual vulnerabilities and on those days, I'm happy we do it.
Thanks for the advice. I noticed bugcrowd has a mailing list with 4100 researchers that get notified when a new site is posted, so I hope it is not too late...
12 comments
[ 3.0 ms ] story [ 38.6 ms ] thread2nd to last paragraph mentioned this which seems like the real issue behind this whole article. Receiving a couple of security emails a day isn't a problem but the fake activity sounds like it's bad for regular users.
No idea how to stop something like this though, maybe put up a page for bounty hunters with some clear guidelines on how they're expected to act?
I might further:
* Fix the disclosure page so that it doesn't reserve thanks for people who find "high or critical" vulnerabilities. Sev:medium in security-researcher-land is XSS and CSRF, both of which probably merit thank-yous. I'd just thank publicly anyone who sends you a valid issue.
* Post to Twitter (under a DoorkeeperSecurity alias) the SHA1 hashes of the titles of disclosed vulnerabilities, so you can "notarize" findings and settle grievances about who found what first.
* Go ahead and live with people sending you annoying security reports. People will do much worse things to you than that over the coming years. If your service does well, eventually people are going to stop "warning" you about DoS-susceptibility, and just start blackmailing you about DoS attacks.
But otherwise, I'm not sure I see the downside here. The alternative, of course, is for people to find flaws on your site and then write up hysterical blog posts about it. Think of the annoyance you're dealing with as a small payment in exchange for (some) control over the security story of your site.
I'm frustrated because adding this page made us a target whereas we weren't one before. I agree we would have eventually become a target regardless, but hopefully this would be because we have a well-known product.
I encourage you to harden your heart. A reward/recognition page is a small price to pay for avoiding an embarassing compromise.
If you really want to quash the general issue, pay some 3rd party to do some real csrf/xss/sql injection pen testing against your sight at the cadence that is appropriate for your dev cycle. If you move slow and deliberately, annual or semi-annual assessments can help you intercept the disclosures. If you're more agile, you'll need to consider something more embedded in your life cycle.
A few other thoughts:
1) Develop your copy pasta for your accept, reject and duplicate submissions. Write in a firm but appreciative tone.
2) For email from anklebiting submitters, refer to your policy. Your policy should say whatever you need it to say. If people want to dispute things, always express appreciation for their effort, but point to "the policy" as the reason things can't be the way they want them.
3) prepare for crazy people. Vuln reward/recognition programs really seem to bring out the old school bbs conspiracy theorists.
I'll also echo what droopybuns stated - creating templates that can address preliminary communication (duplicates, request more info, accept, etc.) will greatly reduce the amount of time you feel as though you are wasting. Some people I know tend to ignore the crazy ones but I generally prefer the "kill them with kindness" approach. One email explaining that you do appreciate the time they spent trying to help secure your site can do a lot to prevent harassment and potential bad press.
Best of luck - responsible disclosure programs are never fun for the person sifting through the reports but once in a while they do expose actual vulnerabilities and on those days, I'm happy we do it.
[1] https://bugcrowd.com/list-of-bug-bounty-programs