-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

"A File Format to Aid in Security Vulnerability Disclosure"
 by Colin Cogle

This article was first published in volume 38:2 (the Summer 2021 issue) of
"2600: The Hacker Quarterly" (pp.57-58).  Please support the official release
and consider purchasing a copy of that issue (paper or PDF) from store.2600.com.

Updated and re-published online 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 organi-
zations describe their vulnerability disclosure practices to make it easier for
researchers to report vulnerabilities.



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 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 per-
son 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 en-
cryption keys, and the preferred way to file your report. Fortunately, there is
a 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
`.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:


 ----BEGIN PGP SIGNED MESSAGE----
 Hash: SHA256

 # This is the "security.txt" file for Contoso.com.
 Canonical: https://contoso.com/.well-known/security.txt
 Canonical: https://www.contoso.com/.well-known/security.txt
 Canonical: https://webapp.contoso.com/.well-known/security.txt

 # For security issues, please contact our security team.
 # Email is preferred, but you may also call us or chat with us.
 Contact: mailto:[email protected]
 Contact: tel:+1-800-555-5555,123
 Contact: MSTeams:/l/chat/0/[email protected],[email protected]
 Contact: https://contoso.com/contact-us#security-disclosures

 # Our PGP key is available in a variety of places.
 Encryption: https://contoso.com/pgp/securityteam.asc
 Encryption: dns:5d2d3ceb7abe552344276d47d36a8175b7aeb250a9bf0bf00e850cd2._openpgpkey.contoso.com?type=OPENPGPKEY
 Encryption: openpgp4fpr:1234567890ABCDEF1234567890ABCD

 # We speak English, Spanish, and French.
 Preferred-Languages: en, es, fr

 # We welcome you to explore our site for bugs, but before you do, please
 # read our disclosure agreement.
 Policy: https://contoso.com/security-policy.html

 # Thank you for your reports!  Why not join our security team?
 Acknowledgments: https://contoso.com/humans.txt
 Hiring: https://contoso.com/jobs#security

 Expires: 2021-12-31T23:59:59Z

 ----BEGIN PGP SIGNATURE----

 iQIzBAEBCAAdFiEE8QHuP28wHqb4E6Yt4H79M4zP+valid+signature+here=
 ----END PGP SIGNATURE----


That's a lot to take in at once, so let's break it down.  Aside from the com-
ments, 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 re-
peated 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 URL's 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 in-
formation.  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 exam-
ple, 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 con-
tacts 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.  Acknowledg-
ments 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 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-clear
sign 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 an informational RFC developed by Edwin
"EdOverflow" Foudil, Yakov Shafranovich, and the open-source community. To learn
more, please visit https://securitytxt.org/.


=== WORKS CITED ===
Chiang, Keifer.  "What Hacking My County's Election Worker Portal Taught Me."
   2600: The Hacker Quarterly, vol. 38:1 (Spring 2021), March 2021, pp 8-9.
Cogle, Colin.  "A File Format to Aid in Security Vulnerability Disclosure."
   2600: The Hacker Quarterly, vol. 38:2 (Summer 2021), June 2021, pp.57-58,
   colincogle.name/blog/security-txt/.
Foudil, Edwin and Yakov Shafranovich, "A File Format to Aid in Security Vulnera-
   bility Disclosure", RFC 9116, DOI 10.17487/RFC9116, 27 April 2022,
   www.rfc-editor.org/info/rfc9116.  Accessed 19 May 2022.

===============================================================================
"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.  You can find this article at: https://colincogle.name/securitytxt

To support articles like this, you can purchase "2600: The Hacker Quarterly"
volume 38:2 (the Summer 2021 issue) by visiting store.2600.com and clicking on
Back Issues.  $5 will get you a copy of the magazine as DRM-free paper or PDF.
===============================================================================

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQ7NZ6ap/Bjr/sGU4FSrfh98PoTfwUCYuiiWQAKCRBSrfh98PoT
fy8/AP0bG1cRIYToWkCWAizVnzSIAR6+sI5JjTriEA3FEhGIOwD8DPcazgJZ/vY+
ZYB8uH4b4gcCDsHOCEroQ8mc+BQmsQ0=
=ZvGw
-----END PGP SIGNATURE-----