I know Google, Facebook, and Github now have this, though Apple, Microsoft, Amazon, Stripe, and Square do not (to rattle off the other tech companies with huge security teams.)<p>But I don't really get it. Why is this a good idea?<p>As 'DyslexicAtheist related, if you put this page on your site, people will crawl for it and find you, and then kick off horrible automated scanners that generate bogus bugs on every site they check, and then submit bounty requests for them.<p>Meanwhile: what serious tester would be impeded by not having this page to refer to, if you have a /security page on your main site, which you have to have anyways for this to work? Recall that most of the fields in security.txt are themselves just URL pointers.<p>I also think the RFC itself is kind of funny. Do not rely on security.txt as authorization to test a site! it says, as if an RFC really had the authority to establish that, rather than an expensive court case in which both sides of the argument will have competing claims about whether testing was allowed or (the US default) not.
A list of all official .well-known files and paths:<p><a href="https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" rel="nofollow">https://www.iana.org/assignments/well-known-uris/well-known-...</a><p>Wikipedia knows some less official ones too:<p><a href="https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers" rel="nofollow">https://en.wikipedia.org/wiki/List_of_/.well-known/_services...</a>
If you’re looking for an example security.txt, you can have a look at <a href="https://www.google.com/.well-known/security.txt" rel="nofollow">https://www.google.com/.well-known/security.txt</a>.<p>There is also this site which lets you create create a security.txt file by filling out some fields: <a href="https://securitytxt.org/" rel="nofollow">https://securitytxt.org/</a>
I think it is great that this proposal is almost done getting through the process.<p>I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords.
Comments should be directed to the IETF last-call list via email:
last-call@ietf.org<p>List info:
<a href="https://www.ietf.org/mailman/listinfo/last-call" rel="nofollow">https://www.ietf.org/mailman/listinfo/last-call</a><p>Guidance on the last call process:
<a href="https://ietf.org/about/groups/iesg/statements/last-call-guidance/" rel="nofollow">https://ietf.org/about/groups/iesg/statements/last-call-guid...</a><p>Archive of comments so far:
<a href="https://mailarchive.ietf.org/arch/msg/last-call/aDZq1M-m4du-wN5b58puSQ_7y2M" rel="nofollow">https://mailarchive.ietf.org/arch/msg/last-call/aDZq1M-m4du-...</a>
An interesting attack for any website that allows customers to choose their own string for use in the url would be to choose the name ".well-known" - I'm sure I've seen sites that take user input and create a folder based on that name. Similar to reddit.com/r/.well-known except as a top-level folder but I can't find a good example right now.<p>Once that happens, they could put up a malicious security.txt file and get free security reports sent to an email of their choice.
I think this is nice but having this in and a lot of other meta data in a machine readable form would be nicer. You could also think of things like licenses a and copyrights.<p>Technically, the problem this specification solves is making it easier to find security related metadata for projects that typically have this information already but just not an easy to find place. So, the next logical step would be making this machine readable so IDEs, project hosting websites, and other tools, can do the right things instead of having to parse files intended for humans with no consistently used syntax.
For people discussing automated tools and noise, prediction: we will start seeing automated tools flagging "missing security.txt" as some sort of vulnerability and I will end up implementing it just to stop the noise. It feels like a lose-lose situation.
This seems like a really poorly thought out proposal.<p>From the draft's [1] intro, which provides motivation for the proposal:<p>> When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly [...]<p>Occam's Razor: they lack the channel to report those vulnerabilities because the company doesn't give a damn about security, not because of some hitherto unsolved technical difficulty.<p>Companies that give a damn about security already have either a "catch-all" contact for security related things displayed on their contacts page, or have dedicated pages detailing what the hell you are supposed to do to report a vulnerability. Companies that don't give a damn will continue to not give a damn and will ignore your document, and will continue to suck at security until someone starts punishing them - monetarily - for such appalling behavior.<p>But let's leave that aside for a moment. Researchers spot vulnerabilities. Need a way to report them. So what's the solution?<p>Apparently, a text file with only one mandatory field...<p>> 3.5.3. Contact<p>> This directive indicates an address that researchers should use for reporting security vulnerabilities. The value MAY be an email address, a phone number and/or a web page with contact information.<p>...which contains... er... a catch-all contact for security related things and or a link to a contacts page detailing exactly what the hell you are supposed to do to report a vulnerability? sigh...<p>But the real kicker is that that the standard doesn't even require that the contact information is up to date or valid:<p>> 6.2. Incorrect or Stale Information<p>> [...] Organizations SHOULD ensure that information in this file and any referenced resources such as web pages, email addresses and telephone numbers are kept current, are accessible, controlled by the organization, and are kept secure.<p>In case the meaning of "SHOULD" is in question see RFC 2119 [2], but basically, they "strongly recommend" that you keep your contact information up to day - instead of, I dunno, REQUIRING it, since having a channel to properly report security vulnerabilities is the ENTIRE POINT of this exercise?<p>/facepalm<p>Are we really supposed to take this seriously? This is simply security theater.<p>[1] <a href="https://tools.ietf.org/html/draft-foudil-securitytxt-08" rel="nofollow">https://tools.ietf.org/html/draft-foudil-securitytxt-08</a><p>[2] <a href="https://www.ietf.org/rfc/rfc2119.txt" rel="nofollow">https://www.ietf.org/rfc/rfc2119.txt</a>