

The Downside of Thanking Security Contributors - pwim
http://www.tokyodev.com/2013/12/03/the-downside-of-thanking-security-contributors/

======
tptacek
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.

~~~
pwim
Thanks for the advice.

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.

~~~
droopybuns
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.

~~~
pwim
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.

------
infosectosser
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.

[1] [https://bugcrowd.com/list-of-bug-bounty-
programs](https://bugcrowd.com/list-of-bug-bounty-programs)

~~~
pwim
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...

------
gnu8
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.

------
marvvelous
> 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?

------
ics
Link to the page/list in question:
[http://www.doorkeeperhq.com/responsible_disclosure](http://www.doorkeeperhq.com/responsible_disclosure)

------
chris_wot
Just note that the list is no longer being maintained.

------
homakov
you definitely exaggerate your problem

