The E-mail arrived quietly in our support mailbox. Pretty good English, but clearly not the writer’s first language, and :
BUG : Password Reset Link Not Expire After Mail Change.
Hey!
I found a token miss configuration flaw in…
Ok. Not the biggest deal of all time, but something that should be fixed. The submitter provided really great instructions on how to reproduce the bug and why we should care. I replied thanking the submitter and got this back:
Hi There
Is there any way to give me a bounty ?Thanks
Baboom. This sounds like the exact situation that Justin Jackson & Jon Buda asked about on this episode of Build your SaaS. We’re a small company. We don’t have a formal bug bounty or vulnerability disclosure program, but I find security fascinating, (at least from the outside), and know bug bounties are a thing. It would be nice to pay a bounty, but how much? What happens next? What if we refuse?
This is what we did, and how it played out.
It’s our first time
My business partner had seen the initial E-mail in the support system so he knew something was up. After a quick discussion about how bug bounties work and asking if he ok with paying something we made the decision to pay small bounties in the neighbourhood of $20 – $50 US per bug, depending on severity, available funds, and how many more reports came in.
I went back to the submitter and said that we could pay but as a very small company with an extremely limited budget he should not expect Apple-style bounties. They were happy with that arrangement, so I fixed the bug.
Then they submitted another but and I fixed that. And another. In all this person submitted 5 “bugs” of varying severity. Some we could barely class as problems but we looked at them all and patched any that needed patching. Some others made us re-think some of the user interface, especially around changing contact or login information, and make plans to change it later.
The reports were both submitted and fixed close together so we lumped everything into one payment. We paid about $100 US for the lot. The submitter asked for payment to go to a random PayPal address that was nothing like the name of the person we were dealing with, then send a screenshot of the completed payment. Pretty sketchy, but they were satisfied.
Writing a Disclosure Policy
I have looked at the bug bounty programs on HackerOne and Bugcrowd, and decided to make a page to point people to when they ask about bug bounties, and to lay down some ground rules, (like don’t DDoS us!). We used Mozilla’s Bug Bounty program and some others from respected companies as inspiration. We included a requirement for detailed reproduction steps, why the bug is actually a problem. This makes it relatively easy to triage any reports we get.
Good thing we wrote a disclosure policy, because as we were finishing up with the researcher another E-mailed us with some bugs, and asking if we have a bug bounty program, and we were was able to respond with a link to the new disclosure page.
Bounty Hunter #2
On Build your SaaS Jon asked if you paid, would you end up on a list of companies that pay, then be flooded with submissions. The answer seems to be at least sort of yes. As we were finishing up with the first submitter another showed up. Submitter #2 had better English than Submitter #1, and was much more thorough. I suspect these two were somehow connected, whether they both post to the same forum or both work for the same person I don’t know, but it felt like we went from a Level 1 pen-tester to Level 2. Submitter #2’s bugs were more creative and more serious than Submitter #1’s. Since #2 showed up just as we were finishing with #1 we were short on cash for bounties, but were honest about it and paid what we could. This seemed well received. I believe we paid about $200 US to Submitter #2.
After once we were mostly wrapped up with Submitter #2 things were quiet for a while, then he submitted one more issue about a week later which we fixed, and since we hadn’t sent the payment yet added to the payment for all of his bugs. Payment was the same sketchy unrelated PayPal + screenshot of the payment method.
Was it worth it?
Short term answer: Yes. At least one of the bugs that Submitter #2 found was serious enough that it warranted immediate attention, so on that level it was worth having someone report it instead of exploit it.
Overall answer: Still yes. For the cost of about $300 US and about a week of my mornings we got outside feedback that made us reconsider some UI decisions from a security standpoint and learned about Content Security Policies and other security headers. Also, the submitted bugs and our knowledge of our systems led us to other related bugs that we fixed as well, so it was a bit like a 2-for-one sale on bug-fixes. And now we have tests written that should prevent these bugs from re-appearing.
Of course I would prefer that we found problems internally before they were deployed, and problems would be discovered at convenient times, but that’s not the real world and I’m happy the problems were found and fixed, and we improved our systems and knowledge as a result.
This all happened back in February and March, and we haven’t had any reports since.
Further Steps
I hear there’s an ISO standard for security disclosure best practices, (apparently ISO 29147 and ISO 30111). I plan on looking them up and do what we can to follow them while balancing that with continuing to improve our product. With a small team it’s always a question of balance, so we’ll keep doing our best!
Has this happened to you?
If I had to bet, I would bet that a lot of small businesses are approached by security researchers this way, but none of us have dealt with them before, we don’t know what to do, and are worried it will be a scam or that we’ll end up on a list and end up spending all our time dealing with bug reports. This feels like something we should talk about.