A File Format to Aid in Security Vulnerability Disclosure
by Colin Cogle
In an age where scoring bug bounties is some peoples' primary source of income, and responsible disclosure is the norm rather than the exception, it can be quite difficult to figure out where and how to report a security vulnerability. I ran into that problem with a vendor of mine. I came across an issue involving unescaped input, and searched high and low for a way to securely report it. In the end, I opened a ticket with their help desk where they had me just tell them the problem in a clear-text email.
I'm not alone, either. In fact, in issue 38:1, fellow 2600 reader Keifer Chiang wrote about finding a bug in a municipal web portal, and the weeks-long ordeal of trying to get his report securely into the eyeballs of the right person.
How many vulnerabilities have gone unreported, sold on the dark web, or simply blurted out on Twitter, only because getting in touch with the appropriate person was impossible?
When a security issue needs to be reported, time is of the essence. There needs to be a quick, standard way to find the right contact information, their encryption keys, and the preferred way to file your report. Fortunately, there is an emerging standard, meekly called the security.txt file.
security.txt is a plain, UTF-8 encoded text file that is designed to be both human- and machine-readable. For ease of discovery, it lives in the "well-known" folder on the root of your web server.
In this article, let's assume we're looking at a security.txt file for the popular fictional company, Contoso:
That's a lot to take in at once, so let's break it down. Aside from the comments, there are many fields you can use in a security.txt file. All fields can appear in any order, most fields are optional, and many of them can be repeated as many times as necessary. Most field values accept a URI, which can be of any scheme except non-secure HTTP.
The first field is called Canonical. This should specify the URLs used to reach this security.txt file, to ensure that security researchers have found the correct file.
Up next is Contact, and this one is mandatory. This is where you specify your points of contact, in URI format, in order of preference. In this example, I've included an email address, a phone number, a link to start a Microsoft Teams chat with our old friends Alice and Bob, as well as a web page with contact information. That should be enough for anyone.
Next, we have the Encryption field, where you provide URIs to download or find an encryption key, usually an OpenPGP key or S/MIME certificate. In this example, the contacts' PGP key can be downloaded from the web server or directly from a DNSSEC-signed DNS zone. The fingerprint is also provided, not only for reference, but in case the researcher wants to download it on their own.
Preferred-Languages is fairly obvious. List all human languages that your contacts understand. This field can only appear once, so list them all in one line.
You may want people to follow some ground rules when searching for or reporting bugs. If you have a security policy, use the Policy field to link people to it.
Of course, no standard would be complete without a few fun things. Acknowledgments links to a resource where this company will thank security researchers who've helped them out, and if you need to bolster your company's own red or blue teams, Hiring is a link to your security-related job postings.
Finally, there is the required Expires field, to make sure that anyone who might be reading this file knows that they have fresh data. The latest draft of the security.txt standard recommends that this timestamp be no more than one year in the future.
Now that you have your security.txt file, it's recommended that you PGP-clearsign it, to prove to your reader that all of the data is authentic and correct. Once that's done, upload it to your HTTPS-enabled web server. Now you can sleep easier, knowing that if there is a problem, a security researcher will know how to reach you.
Oh, and that vendor I mentioned at the top of the article? They now have their own security.txt file.
The security.txt standard is currently a draft RFC being developed by Edwin "EdOverflow" Foudil, Yakov Shafranovich, and the open-source community.
To learn more, or to contribute to its development, please visit securitytxt.org.