Sometimes it's really difficult and time consuming to find a way to report a security vulnerability. But there is a very simple solution for that.
|Published:||Sat, November 4, 2017, 15:35|
|Updated:||Sun, November 5, 2017, 20:15|
Ed Foudil has proposed security.txt as a standard method for making it easier to report security issues. It's a plain text file with contact info that should be located in the .well-known directory of a web site (or root of a file system). Currently it's a "Internet draft" that has been submitted for RFC review.
Over the last three months I have published 12 fresh security issues on my blog. While finding the issues has typically only taken a few minutes, finding somewhere to report the issue sometimes have be a real pain and very time consuming.
In most cases I have had to contact first-line customer support and try to write in a way that will ensure that they understand that they need to report this to the right party. Often this can work ok, but I have even experienced to be turned down by the customer support because they have not understood what I was trying to tell them.
In the case with IKEA I spent so much time trying to find the correct contact point. They had no general e-mail addresses or anything anywhere. I ended up e-mailing three press contacts with the issues, and it took three weeks before I got their attention and got to tell them what the issue actually was. And according to IKEA this is actually the way any security issue should be reported. security.txt would have been a much better solution.
In the case with the insurance company Gjensidige they managed to lose one of two reports before it reached the IT department. security.txt would have solved this nicely.
In the case with 1 million+ Norwegian Social Security numbers etc. exposed, the insurance company Tryg did not read the e-mails sent to the specified contact e-mail address, and Infotorg - who was responsible for the delivering the data - just stopped responding. It was probably a lost case for Infotorg, but at least Tryg would have been notified with a security.txt.
In the case with the company vulnerable for for SQL injection for 10 years I did not know if their customer support form worked at all as I never got a reply. Writing to an e-mail address specified in security.txt would've helped here.
In most cases the info would have been delivered directly to the correct persons instead of being delayed in some kind of first-line of customer support. You want it to make it easy to report a security issue, and you want the report to get to the right destination asap.
The only directive that must be present in security.txt is Contact, which lets you specify either an e-mail address (maybe not very smart considering spam) or a phone number or a URI that provides contact info. The order defines the preferred method of contact.
In order to ensure the authenticty of the security.txt one should use the Signature directive to sign it using either an external or internal signature.
The Encryption lets you add your key for encrypted communication, like your PGP key or similar.
The Acknowledgement allows you to link to a page where security researchers are recognized for their reports.
It's a proposal, so be sure to check out securitytxt.org for the latest update of the specification. Also, at the time of writing, you should take a look at the draft branch at https://github.com/securitytxt/ for the latest development. There's also some interesting discussions on the issue tracker of the same project.
Contact: https://example.com/security-contact-form/ Contact: https://example.com/mailhide/security Contact: 555-2368 Signature: https://example.com/.well-known/security.txt.sig Encryption: https://example.com/pgp-key.txt Acknowledgement: https://example.com/security-hall-of-fame.html
This is one is easy. Please add support for security.txt - as soon as you can - to make the web a safer and more secure place for us all.