Hacker News new | ask | show | jobs
by capt8bit 3996 days ago
The Security Researchers that I work with, and myself included, usually follow the RFPolicy:

http://www.wiretrip.net/p/rfpolicy.html

This responsible disclosure policy was first put together by rain.forest.puppy. (One of the first people to discover SQL injection, and one of the founders of the OSVDB.) We have had good results with it, and nearly all the people that we have disclosed vulnerabilities to have found it to be more than fair, and motivating. The researchers have found that it also gets results quickly.

By default it requires you to disclose that you are following this policy, disclose the vulnerability, as directed in the document, then give them 5 days to respond. If you have done everything you could to contact them, and they will not respond, then disclose.

However, as others here have been saying, it may take a while to fix this problem. If they do respond, they may want to "negotiate" more than 5 days to fix the issue. That's great. Get some details, set up a reasonable timeline with them, and get a contact's information. Then it's up to you to hold them accountable. Sometimes this means disclosing on the agreed upon deadline, other times it means following up and seeing if more time should be given before disclosing.

The main issue, as you point out, is keeping users/data safe. If the company is unwilling to work with you, not disclosing could put other people at risk, because you didn't stop unsuspecting users from signing up for the service. On the other hand, disclosing without working with the company can unnecessarily put the current users/data at risk.

It's good to have a balance. The RFPolicy has helped me to have that balance when doing responsible disclosure. Give it a look over. It's not too late to use the RFPolicy now.

1 comments

Thank you for the link of the policy, it seems to be a fair one.

I just read it and it looks like you are misinterpreting it.

> then give them 5 days to respond > they may want to "negotiate" more than 5 days to fix the issue

"5 working days" is not the same at all than "5 days", think of public holidays and week ends ...

You are absolutely right. Big difference. I did not mean to imply that it was 5 days, regardless of holidays/weekends.

In fact, because we are online more often during holidays, it is during holidays that we most often find vulnerabilities that we need to disclose.

Especially during December, we are much more lenient.

> I did not mean to imply that it was 5 days

My comment was supposed to be an addendum but I failed by nitpicking and questioning your interpretation. I'm sorry.

As a security researcher, may I ask you these questions:

Which channel are you using as a first contact ? Would it be enough for me as a saas supplier to monitor security@myservice.com ? I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?

security@ is common, but it's unlikely that I'm going to blindly send an email to an address without knowing it is monitored, except as a last resort.

Having a web page on your website that is easily identifiable via google is probably one of the best. You can put a PGP key there if you like. You will find that security researchers have a wide range of caring about how secure the communications are, so don't be surprised if lots do not bother to use it, since it's still your data that is at risk and not theirs. Alternatively, there are bug bounty programs for incentivizing researchers (both to find bugs, but also to play nice), and those generally work over HTTPS, so it's encrypted to that extent.

HackerOne recently launched a Directory service for security contacts: https://hackerone.com/blog/wheres-that-security-at I don't think that is the most common way by far, but if you particularly care, you might want to use that.

> My comment was supposed to be an addendum but I failed by nitpicking and questioning your interpretation. I'm sorry.

Well, I appreciate you pointing out where I was vague. You provided, and brought about, some important clarification.

> Which channel are you using as a first contact ?

It takes quite a bit of effort to make a nice writeup for an identified vulnerability, and hunt down where to send it. Generally, someone willing to take the time to be nice and send in a detailed report, is willing to look for the best channel to send information through.

I start by looking through the "About" and "Contact" pages of the web application or service that I found the vulnerability on. If they have a reference to a bug tracking system, a system administrator, or a security contact, I send it there. If they are all emails, I usually send a message to all of them, to make sure that someone receives it.(If I don't know who is going to get the message, I am initially vague on the vulnerability, and ask for a technical contact to forward the technical information to.) Otherwise, I look at whois information to see if there is a good technical contact. If I still haven't found a good contact, I send a message to all of the emails listed in the RFPolicy. If all of those messages bounce, I send a message to any email address I can find for the domain. And once, I even called in to a sales line after all of this, and explained the situation. They got me in contact with "Bob the website guy", to take care of the issue.

I have never received a bounty for any of these. I just want to do my best to make sure it gets taken care of.

> Would it be enough for me as a saas supplier to monitor security@myservice.com ?

I think this would be a good backup plan. Probably safe to add forwards for all the RFPolicy emails.

> I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?

My recommendation would be to make it easy and clear to find how you would prefer to receive notices. If you include your PGP key on your contact page with a message that all security reports should be encrypted, most I know are willing to do so. If you prefer them to send it via an HTTPS "Contact" page, say so, and most will see that and send it via that channel. Just like your saas, if you make it intuitive and useful, they will be happy to use it.