People here dislike HackerOne, but afaiu it solves this exact problem. It's the first line of ‘support’ for security reporters.
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.
posting your email in a not easily parsable way can save you a lot of spam. (rot13 it, break up characters, etc). Atleast that should cut most of the spam. This might be not standard, but I do not really see why we would need security.txt to be parsable by robots.
security.txt is a flag that you may have a bug bounty program, and as a result are a potential source of revenue.
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.
> 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.
I'm not sure I buy into the idea, but it couldn't have been sold any better. That security.txt generator is such a great way to get people on board. The whole website is really good at explaining the project.
It’s cute but it generates a five line plain text file. I would argue that a better way to sell the idea would be to create an Apache and nginx module so you could specify this stuff from those config files. It would make adoption seem easier to more people.
One aspect that is not reflected in this format is that the site/company might have a specific routine for reporting vulns. When I happened to write to Node (iirc) about some potential problem, the mail was just redirected to HackerOne, converted to some kind of a draft, and I got an automatic response saying I need to create an account there. In true marginal-nerd fashion, I have some opinions on which of my email addresses go where, so the account remains uncreated and the problem unreported by me. And Node didn't specify anywhere that this reporting works through HackerOne.
(I also realize that this comment is probably not the right place to complain about the format, but eh.)
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:
A top-level security.txt sounds like a better idea than hiding it under .well-known. I wouldn’t want anyone without access to
the web server’s root to be telling me what the security policy is, anyway.
Having it at top level makes it a sibling / analogous to robots.txt so there is some consistency to the pattern.
Dammit I was hoping this would include password requirements. I remember reading about a similar proposal on HN before.
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"
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.
Whois is not a good place for this data. Whois data is typically abused by spam bots (and most people don’t look there), it can’t be easily extended with security-specific info (a link to the encryption key? a link to the full security policy?), it works only for the registered domain (you can’t have different whois for maps.google.com and mail.google.com), and some registries might have policies that make it difficult to fetch WHOIS data (eg. by blocking IPs of cloud providers, or by forcing you to go to a website to see full subscriber information).
This is all done over TLS connections, including the link to the encryption key. So the provenance is already at the certificate level. Using PGP means that this provenance can be increased past that level if required.
I'm sure they'd be very excited if I sent them PGP encrypted email message using a public key extracted from some possibly stale public cert of their http server.
Public keys can be big + Why keep the key there if it is already available somewhere else. and the draft allows 3 ways to add a key
- by uri
- by OPENPGPKEY DNS record
- by key fingerprint (assuming it's on a public keyserver)
IMO this totally solves the wrong problem. It's not really so much about "who do I contact if I find a security problem on a website", it's more about the problem on the other side "How do I separate the spam and low quality bug reports from actual defects, especially if I have a bug bounty program that attracts low quality bug reports."
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.")
> It's not really so much about "who do I contact if I find a security problem on a website
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
One is a problem for the reporter, the other is a problem for the recipient.
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.)
How did you arrive at a blockchain? That's putting the cart before the horse, so to speak. Just do what these real-world sites already do, put up a list of researchers and their bounties.
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...
> especially if I have a bug bounty program that attracts low quality bug reports
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.
It always intrigued me: why is it somebody else's job to secure a company's website? This is completely backwards. Rather than investing into security, they let somebody else fix the problems while leaving their users exposed. 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 somebody else's job to secure a company's website?
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/
I don't think this should be a standard pe say. Maybe more of what is a best fit for your risk appetite. Because I could easily see this as a flag to welcome people to attack your website looking for bounties. If that is the case how are your blue team people going to know the difference?
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.
Seems like a reasonably good idea. More of a question about RFC’s than the spec itself. I noticed while reading the RFC it mentions this:
> 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.
I agree, it definitely seems that the phrasing there needs work. Overall I would say most RFCs are well substandard especially when compared to ISO standards which tend to be extremely precise. That being said, interoperability within tech is amazing so perhaps there is something to be said about the idea of loose standards and working code after all.
[+] [-] goatsi|5 years ago|reply
It apparently attracted automated scanners and the signal to noise ratio was atrocious.
[+] [-] aasasd|5 years ago|reply
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.
[+] [-] Anunayj|5 years ago|reply
[+] [-] mike_d|5 years ago|reply
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.
[+] [-] GoblinSlayer|5 years ago|reply
[+] [-] kjrose|5 years ago|reply
[+] [-] peterthehacker|5 years ago|reply
> 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.
[0]https://g.co/vulnz
[1]https://hackerone.com/github
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] coolreader18|5 years ago|reply
https://www.google.com/.well-known/security.txt
https://www.cloudflare.com/.well-known/security.txt
https://www.reddit.com/.well-known/security.txt
https://github.com/.well-known/security.txt
[+] [-] djcapelis|5 years ago|reply
(Expires isn’t optional in the proposal on the website.)
[+] [-] not_knuth|5 years ago|reply
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.
[+] [-] mttpgn|5 years ago|reply
[+] [-] nicbou|5 years ago|reply
[+] [-] IgorPartola|5 years ago|reply
[+] [-] aasasd|5 years ago|reply
(I also realize that this comment is probably not the right place to complain about the format, but eh.)
[+] [-] achillean|5 years ago|reply
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:
https://beta.shodan.io/host/5.28.193.120
[+] [-] nwcs|5 years ago|reply
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/
[+] [-] geekone|5 years ago|reply
[+] [-] Old_Thrashbarg|5 years ago|reply
[+] [-] cmsefton|5 years ago|reply
https://news.ycombinator.com/item?id=19151213 (2019) https://news.ycombinator.com/item?id=15416198 (2017)
[+] [-] loloquwowndueo|5 years ago|reply
Having it at top level makes it a sibling / analogous to robots.txt so there is some consistency to the pattern.
[+] [-] dyeje|5 years ago|reply
[+] [-] sodality2|5 years ago|reply
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"
[+] [-] dang|5 years ago|reply
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)
[+] [-] dheera|5 years ago|reply
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.
[+] [-] Kwpolska|5 years ago|reply
[+] [-] upofadown|5 years ago|reply
[+] [-] megous|5 years ago|reply
[+] [-] ddevault|5 years ago|reply
[+] [-] Anunayj|5 years ago|reply
[+] [-] hn_throwaway_99|5 years ago|reply
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.")
[+] [-] geek_at|5 years ago|reply
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...
[+] [-] tgsovlerkhgsel|5 years ago|reply
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.)
[+] [-] pavel_lishin|5 years ago|reply
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.
[+] [-] Kwpolska|5 years ago|reply
[+] [-] IncRnd|5 years ago|reply
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...
[+] [-] EE84M3i|5 years ago|reply
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.
[+] [-] einpoklum|5 years ago|reply
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.
[+] [-] 3gg|5 years ago|reply
[+] [-] Thorrez|5 years ago|reply
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/
[+] [-] zer0faith|5 years ago|reply
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.
[+] [-] tequila_shot|5 years ago|reply
[+] [-] pseudoramble|5 years ago|reply
> 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.
[+] [-] anamexis|5 years ago|reply
> For web-based services, organizations MUST place the security.txt file under the "/.well-known/" path;
[+] [-] willeh|5 years ago|reply
[+] [-] jcims|5 years ago|reply
[+] [-] Retr0spectrum|5 years ago|reply
The advantage of PGP is that it can be verified entirely out-of-band, and distributed widely.