Security.txt
securitytxt.org
securitytxt.org
It apparently attracted automated scanners and the signal to noise ratio was atrocious.
The fact that the industry currently needs this kind of solution is absurdly comedic. Basically, it would make actual sense to require people to pay ten bucks when posting a report—if they think the report is reasonable and that they would get paid for it.
HO will just create paid tiers where for a smallish subscription price, people actually take your reports seriously.
Going to need a lot of work in the next few years to make something like this viable, but ETH could make it possible
If Eth has a solution for this, it would mean it basically solves trust in general, which is a persistent pain in all of infosec.
It is time arbitrage between big companies taking security seriously (willing to pay large bounties) and that amount being higher than a monthly or yearly wage in some internet-connected regions. If they throw enough nets into the sea all year, eventually one pays off and they end up living quite well.
The web is not a junkyard.
And even if it wasn't, there is plenty of namespace room to put every file someone argues for in a 2-page RFC at root. After all, there are only 1024 low-numbered TCP ports and we haven't run out of those yet.
And it’s Anglocentric to continue to unnecessarily put multiple English words into the path; those can’t be touched-up with a later RFC to support Japanese in the file content via a Lang attribute.
The whole thing is shit bad, I’m sorry. Just come up with something that makes fucking sense for once.
> A link or e-mail address for people to contact you about security issues. Remember to include "https://" for URLs, and "mailto:" for e-mails
Using a landing page should improve the signal/noise ratio. Google, for example, points to a landing page [0] and GitHub points to their HackerOne profile.
https://www.google.com/.well-known/security.txt
https://www.cloudflare.com/.well-known/security.txt
(Expires isn’t optional in the proposal on the website.)
An expiry date brings along with it yet another maintenance burden for questionable benefit.
So if you really don't want the burden, just set a date in the year 9999 or something.
Design is hard. Good design makes implementation simple.
https://securitytxt.org/.well-known/security.txt
> # If you would like to report a security issue
> # you may report it to us on HackerOne.
> Contact: https://hackerone.com/ed
> Encryption: https://keybase.pub/edoverflow/pgp_key.asc
> Acknowledgements: https://hackerone.com/ed/thanks
The last thing I need is one more thing to have to remember and update.
By the looks of it, a few others feel it is non-critical and have just skipped it too.
HTTP already has an Expires header: https://tools.ietf.org/html/rfc7234#section-5.3
Zero maintenance required but still gives a rate-limiting and time window function.
> If information and resources referenced in a "security.txt" file are incorrect or not kept up to date, this can result in security reports not being received by the organization or sent to incorrect contacts, thus exposing possible security issues to third parties.
Yes, the information could change after you write the file. No, it is not possible to know, when you write the file, at what future point the information will become incorrect. The document should have a "last reviewed" date, then the consumer can decide for themselves if it has been updated recently enough to be trustworthy.
1: https://tools.ietf.org/html/draft-foudil-securitytxt-11#sect...
https://www.google.com/search?q=hiring+well+known+security+f...
Edit: If one is not up for the 2min it takes to parse some publicly available list.
More code || complexity == greater likelihood of bugs (including security bugs).
As ironic as a security bug in a security.txt serving module would be, it's probably best we avoid that possibility and let the ordinary, highly scrutinised file serving code handle it instead.
It would also be nice to have libraries for the popular frameworks
(I also realize that this comment is probably not the right place to complain about the format, but eh.)
Though the UX designer in me thinks that if the policy is important, it would be better to put in up on a webpage and slap that into the ‘contact’ field—as a neighbor comment suggests. At least when the whole process turns out to sidestep email completely.
I'm not creating an account just to do someone else a favour.
I will send an email and that's it. If you don't have an email address then you're not getting a message from me.
It's disappointing how frequently this comes up.
https://beta.shodan.io/search/report?query=http.securitytxt%...
We've been indexing it for a while now and we haven't seen the number of websites that support it change significantly. It would make notifying organizations easier if this was a more widely-adopted standard. This is how it looks like when you pull an IP that has a service with that file:
Make sure you read through the actual latest draft (especially section 6): https://tools.ietf.org/html/draft-foudil-securitytxt-11
Also, we are in the end stages of the IETF approval process so this should be official later this year (if all goes well): https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
I tried again and waited, and after 10 or 15 seconds, the page finally loaded.
https://datatracker.ietf.org/doc/html/draft-foudil-securityt...
https://news.ycombinator.com/item?id=19151213 (2019) https://news.ycombinator.com/item?id=15416198 (2017)
Having it at top level makes it a sibling / analogous to robots.txt so there is some consistency to the pattern.
It's increasingly common for server configurations to have a reverse proxy routing requests to internal containers or servers. Things like SSL renewals are often handled by the reverse proxy (because reasons [1]), so those requests don't get routed to the internal hosts by default.
Site-specific stuff, like this file, probably belongs in the site's root directory.
This is a bit bike-shedding though. It's only a small aggravation to work around.
[1]: Because you want to automate as much of the configuration as possible, so when a new hostname is added to a container or internal server, an SSL certificate just magically happens for it. This requires changes to the reverse proxy's configuration, and that's not something you want the internal containers doing, so it falls to the proxy to handle these itself. Letting the containers handle their own SSL setup means you have to have some kind of privileged communications channel from the container up to the reverse proxy, which is undesirable.
IMHO, index.html and favicon should be the only files living at top level, and I guess robots.txt since that's a de facto standard (and soon to be actual standard iirc)
Same with favicons, although you can specify an arbitrary path to most favicons using index.html
Certificate Authorities doing ACME (like Let's Encrypt) use /.well-known/acme-challenge/ while those who've rolled their own solution or maybe just adapted some manual process for this modern era are required to use paths starting /.well-known/pki-validation/
Previously to this the problem was if you hand roll solutions a customer eventually says "Oh, I can't create http://example.com/proof.txt you asked for because of [some stupid corporate reason] how about if I name it http://example.com/proof.doc ? And also it will be a JPEG screenshot of an Excel spreadsheet with your text file in it". And eventually your frustrated employee says "Fine, fine, whatever it takes" and next thing you know your policies are so relaxed that a bad guy is able to get a certificate for example.com by uploading the proof file to http://pastebin.example.com/XQGBLP. Oops.
So the Ten Blessed Methods fix a bunch of stuff in this space, clearly control over pastebin.example.com shouldn't get you an example.com certificate for example, but also requiring the files go in specified places in /.well-known/ means chances are if other people can create those files you likely also have a dozen other directory traversal type vulnerabilities and maybe you need to check yourself before you wreck yourself.
Such level playing field rules prevent a race to the bottom for CAs because they don't need to worry that their competitors get an edge by being more lenient than they are, if a competitor breaks the rules you can just rat them out.
[0] - https://www.iana.org/assignments/well-known-uris/well-known-...
The way I saw it described was a field for password security requirements, a field for an API url to let you change a password, etc. This would allow password managers to easily and simply change account passwords en masse. I suppose there are security risks as well, so maybe an email going out saying "an automated password change request was made, these often come from your password manager but only if you initiated it. If you want to approve this change, click here"
https://github.com/apple/password-manager-resources
or the related:
https://github.com/w3c/webappsec-change-password-url
But mainly if you are responsible for a system and you're willing to do work to improve security your first focus should be "implement WebAuthn so my users can stop worrying about passwords entirely" not "I wonder if more complicated password handling would help somehow?"
Show HN: Scanning the Web for Security.txt Files - https://news.ycombinator.com/item?id=25605164 - Jan 2021 (33 comments)
The “security.txt” proposal reached last step in the IETF process - https://news.ycombinator.com/item?id=21766868 - Dec 2019 (89 comments)
Security.txt (2017) - https://news.ycombinator.com/item?id=19151213 - Feb 2019 (54 comments)
Security.txt - https://news.ycombinator.com/item?id=15416198 - Oct 2017 (141 comments)
Also, how do I know whether to believe the link to the encryption key? That stuff should be in the HTTPS certificate, not a text file. Just use the server's public key to encrypt communications to the website owners.
Just put a public key into the address field, for example. More abuse of field names is good because it will keep trip up the bots that use e.g. the address field as a spam mail address or pass it to data brokers.
I'd love to see a data broker say "John Doe lives at === BEGIN PGP KEY === 0xA3243ABC3F... Do you want to dox them? Yes/No" and more spam mailers waste their money attempting to send ad mailers to "=== BEGIN PGP KEY === ..."
I think what is needed more is a community-managed "reputation score" for security researchers that could be used to indicate who has submitted high quality defects in the past. I shit on pie-in-the-sky blockchain schemes all the time, but this actually seems like one where I could imagine it being useful, i.e like this:
1. A site owner publishes their security team's public key in a well known location, similar to what is described in the security.txt proposal
2. When a user submits a bug report to some site that the owner seems is a bug, the user can sign something on the blockchain that states "User X found a [high,medium,low] defect" on our site.
3. Then, when a user wants to submit a defect to another site, they could show their past history of high quality bug submissions to past sites, and those submissions could even be scored based on some value of the site owner (e.g. finding a high impact defect on Apple would result in a high "reputation score.")
And you're right to, because they're mostly nonsense.
One of the issues with your proposal is that if I'm a security researcher, I now have to pay to maintain my reputation using cryptocurrency.
Sorry to burst your bubble, hn_throwaway_99, but this is the same kind of nonsense idea that you typically scoff at. It offers no new benefits, while adding new problems.
As a reporter, if I can't find where to report it, you'll find out about your issue when someone forwards my blog post to you. If you ignore my e-mailed report because you don't want to spend the resources on it, e.g. because I haven't built a reputation score, same thing.
Most importantly: If the only way to report a security issue is through a platform with a "community managed reputation score", I'm much more likely to ignore that platform and again, you'll find out about your vulnerability from a blog post.
security.txt actually told me about a contact address for Cloudflare that isn't HackerOne. (HackerOne, in particular, is on my shitlist because they impose terms of service that deter disclosure unless the vendor agrees, and they don't let you publish through their platform if the vendor is unresponsive. If the only way to report to you is through HackerOne... see above.)
If you find a vuln and publish it and the company does not have an explicit bug bounty program allowing such things, you may be sued or face other legal action.
I know several security researchers who have been sued for hacking, in many countries (mostly across US and Europe), because they assumed they were doing a "good thing", whereas the law doesn't care - it only cares about what is legal or not legal. Apart from the hacking charges, the very nature of bug bounties means it's pretty easy for the lawyers to add a coercion/blackmailing charge as well, which makes it more serious.
This doesn't mean that you won't get sued, but it does increase your likelihood of winning such lawsuits when you haven't committed any crimes during your security research & disclosure.
You are not required to ever tell the affected parties at all, and afaik you are also free to stockpile and sell exploits as long as you only sell them domestically (IANAL & TINLA).
If you've bought some software you install on your computer - like the good old days ( :) ), it's more fair game as you said.
There're only three categories IMO (besides black hat):
1) The researcher disclose a vulnerability the proper way and all's good
2) The "researcher" did something that could cause harm and were punished
3) The system is utterly broken
I have seen all happen and the ones people are up in arms about have always been in category 2 or 3. Your last sentence about blackmail is in category 2 as demanding money for a proper disclosure from someone without a bug bounty program is the definition of blackmail.
"Whoever, under a threat of informing, or as a consideration for not informing, against any violation of any law of the United States, demands or receives any money or other valuable thing, shall be fined under this title or imprisoned not more than one year, or both."
I consider going public directly less risky than talking to the company first: They're much more likely to make legal threats/try to sue you if they think it can help hide their embarrassment. Once public, that incentive goes away, they're in the public eye, if they do go after you they can no longer prevent the disclosure, and you have a decent chance that the additional attention this generates will make them reconsider before you have to spend money on lawyers.
Cannot confirm. I bought a windshield for my '01 Ford Focus and found a major security bug on their site [1] (they linked a JS file from a non-existant domain)
I talked to CERT, the clerks at the store, tried to contact the owner on linkedin; heck it was even published in one of the largest newspapers of my country but never got anyone who understood the problem or cared.
In the end the bug was fixed because I wrote them on facebook and the kid who's job it was to manage their facebook site was also the web admin
[1] https://blog.haschek.at/2019/threat-vector-legacy-static-web...
IMO security.txt provides value for when you DON'T have a bug bounty program. If you don't already have a 'front door' for how to send you security information, you're not going to get it.
Also, I would put some money on someone finding a show stopper bug like shellshock/heartbleed/deserialization-bug-of-the-week/etc and contacting folks from their security.txt in sync with their public release sometime within the next few years.
Nobody is going to download a blockchain client from a bounty website in order to look at a text file. That's like the security researcher interviewing an employer.
I think what you are actually referencing is a distributed database, not a blockchain. But, the database you mentioned in your post isn't distributed, it's centralized...
https://en.wikipedia.org/wiki/List_of_%2F.well-known%2F_serv...
I remember such files used to go into the root of the website's hierarchy; I guess it's nice that now they're mostly bunched in a subfolder.
Some people find bug bounties to be lucrative, especially in low cost of living countries. Other people find them fun. Other people find they look good on resumes. But no one is required to participate in them. If you don't want to spend your time looking for vulnerabilities in other people's software, don't do it.
>Rather than investing into security
Running a bounty program costs money, both to pay the participants as well as to pay employees to investigate the reports (most of which are junk). Also it's not a one or the other. You can run your own internal red team while also running a bug bounty program.
>they let somebody else fix the problems while leaving their users exposed
It's usually not the bug bounty participants who fix the problem. Usually the bug bounty participant reports the problem, then the company fixes it.
>At this point, it is more ethical to sell whatever vulnerabilities you find to the black market than to "ethically" disclose them.
Why is it more ethical to sell them on the black market? The black market is composed of people who actively want to harm others for their own benefit. Seeking them out and selling them tools specifically for that purpose is unethical. I don't see what's ethically wrong with reporting a vulnerability to a company through its bug bounty program.
There are of course other options besides those 2. Full disclosure for example.
Also you could sell it on the grey market to people who promise to only use it for legal purposes (e.g. for governments to legally hack people). https://zerodium.com/
As far as the info contained within the txt file there should only be a email address or contact info if you found something serious absolutely nothing more. No reason to intentionally/unintentionally provide information used for recon.
About the automated scanners... adjust your scope to avoid the file.
* https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
> By convention, the file is named "security.txt".
Isn’t the point of the RFC so that it wouldn’t be by convention anymore? Or are they saying the idea for the name was from prior conventions? Or maybe I’m just reading into it too much and it doesn’t really matter.
> For web-based services, organizations MUST place the security.txt file under the "/.well-known/" path;
The advantage of PGP is that it can be verified entirely out-of-band, and distributed widely.
On a more serious note, all these sitemap and bot-friendly standards for webpages always tend to fail. Even RSS, which is probably the most important standard in this space, has issues getting more adoption.
This sounds like mafia
Is there a good argument for not making it TOML? You'd get parsers for basically every platform, for free.
It clearly has some INI-style format. Why not a well-specified one?
Since it has a structured data format, computers will parse it sooner or later. Why bother setting off comments with `#` at all if it's purely for human consumption? Why even have a standard, security.txt could just be "this is the place where you write whatever you want to about security, here are some suggestions as to what other people might find useful".
I'm not hearing good arguments for not making it TOML...
barring that, (not much space for public keys and preference flags i guess), how about DNS TXT records.
just some file on the root of the webserver seems a security issue itself. typically less people have keys to DNS. also, rare today, but not all domains have webservers.
seems dangerous that anyone who can modify the root of a webserver content can impersonate security contacts/pubkeys.
Expires: Tue, 16 Mar 2021 05:09 -0400
Maybe slow down, read the spec, and proofread your comment for obvious errors before trying to troll for no reason.
If this is intended to be some kind of standard, it should follow other standards. I understand that this is "only" in the generator, but why even there?
I am French and my Chrome is set to US English. I just opened a FF session, switched to French and the input is dd/mm/yyyy.
I like that the spec uses a universal and unambiguous format. I especially like that this generator is localised to my region though.
<input type="date" placeholder="YYYY-MM-DD" class="input" required>Example: from line #1 "proper channels" - This is subjective as hell.
robots.txt
humans.txt
.well-known/security.txt
favicon.ico
ads.txt
app-ads.txt
Part of me thinks that the root index.html should have link or meta tags for any and all of these. HTTP headers would also work. I get that robots.txt and favicon.ico are historical and humans.txt is cutesy, but this is getting kind of polluted. Perhaps I'm missing some obvious reason for why we're still doing the .txt thing?
As is implied by .well-known/security.txt there is in fact a whole registry for such well known URIs living under the /.well-known/ path https://www.iana.org/assignments/well-known-uris/well-known-...
> Part of me thinks that the root index.html should have link or meta tags for any and all of these. HTTP headers would also work.
As it is, anything interested in MTA STS can get the associated well-known URL and everything else doesn't care. If we put that into index.html or every HTTP header then everybody is burdened even if they didn't care.
> Perhaps I'm missing some obvious reason for why we're still doing the .txt thing?
If there's a significant software stack in which you're more likely to get what you expected from foo.txt than from naming it just FOO or foo then unless there is also a significant stack in which foo.txt can't work you'd be crazy to insist on not having the extension.
The IETF and W3C do not have enforcement arms, so if they standardise something that's harder to get right, less people get it right, harming its adoption. Sometimes that's just the price you must pay for something that actually delivers on its intended purpose - but often it is not and you should look for the simplest thing that works.