Colin Cogle's Blog

"A File Format to Aid in Security Vulnerability Disclosure"

by Colin Cogle

This article was first published in "2600: The Hacker Quarterly", Volume 38:2. Please support the official release by buying a copy of the magazine:

Paper copy

DRM-free PDF copy

Updated May 19, 2022.

Abstract

When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. Fortunately, there is a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.

Introduction

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 a problem 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

the Spring 2021 issue of "2600: The Hacker Quarterly",

fellow 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 a standard, meekly called the "security.txt" file:

RFC 9116

"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 `.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 webpage 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 have 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 "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 exists as RFC 9116, developed by Edwin "EdOverflow" Foudil, Yakov Shafranovich, and the open-source community. To learn more, please visit their web site at:

https://securitytxt.org

=================================================================

Previous Blog: "Hacking Haswell ThinkPads' Firmware"

Next Blog: "SSHFP Records on Windows Server"

=================================================================

"A File Format to Aid in Security Vulnerability Disclosure" by Colin Cogle is licensed under:

Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA).