Security.txt Standard Proposed, Similar To Robots.txt (bleepingcomputer.com)
An anonymous reader writes: Ed Foudil, a web developer and security researcher, has submitted a draft to the IETF — Internet Engineering Task Force — seeking the standardization of security.txt, a file that webmasters can host on their domain root and describe the site's security policies. The file is akin to robots.txt, a standard used by websites to communicate and define policies for web and search engine crawlers...
For example, if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue. According to the current security.txt IETF draft, website owners would be able to create security.txt files that look like this:
#This is a comment
Contact: security@example.com
Contact: +1-201-555-0123
Contact: https://example.com/security
Encryption: https://example.com/pgp-key.tx...
Acknowledgement: https://example.com/acknowledg...
Disclosure: Full
For example, if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue. According to the current security.txt IETF draft, website owners would be able to create security.txt files that look like this:
#This is a comment
Contact: security@example.com
Contact: +1-201-555-0123
Contact: https://example.com/security
Encryption: https://example.com/pgp-key.tx...
Acknowledgement: https://example.com/acknowledg...
Disclosure: Full
There's going to be <a href>> tags in security.txt? No? Then don't make the links clickable in the fucking summary.
#DeleteFacebook
Hell, I'll be implementing that Monday morning for a couple servers, screw waiting for the standard.
Yay! Zillions of more juicy Email addresses and phone numbers to collect and spam! Robots will sweep up all that data and hammer the "contacts" to death.
This seems like something they can put on their contact info.
The point of robots.txt is that automated web crawlers use it.
This seems like all it would do is allow for tons of spam to be sent to the target address.
Tools will scour the web to find the contact email addresses, and spam the crap out of them with pitches for various "security" products.
How long until root kits are updated to change the contact info to look like lolz@yeahnope.com and the phone number of some random Equifax branch office? -PCP
A "security.txt" file that says this specific account and contact information is very valuable and very sure of their security, please hammer it with all the automated tools you can. Also a great starter for social hacking should you be inclined that way.
It's almost like https://www.w3.org/P3P/ wasn't already a thing that died with a whimper 10 years ago. On the other hand, an almost syntax-free text-file might gain some more traction, even if I fail to see how that's actually useful over some "About" or "Contact" link on the website menu.
The example.com domain is getting abused again and again. I almost pity its owners.
This is not a solution to any real problem.
The problem is companies that don't want to hear about vulnerabilities. Those companies are unlikely to put up security.txt entries.
"None so deaf as those that will not hear. None so blind as those that will not see." Matthew Henry.
The real "Libtards" are the Libertarians!
...who should be competent enough to get the information to a qualified person to rewolve the issue.
Thanks for mentioning that. I totally missed the lycantrhopy part.
A dingo ate my sig...
20 years ago this would have been a fantastic idea. In 2017, this is just another potential security hole. Spammers will scrape and hit those contacts hard.
Also, as another pointed out, may offer little protection, since hackers can, presumably, can alter the security.txt file too. It's not even signed, so how would one know which is the correct one? Presumably, Google, Microsoft, Apple, etc could maintain a security.txt registry and monitor changes. Then flag such changes in web browsers that can do such lookups. That could help, but increases the complexity. Whois, while far from perfect, already provides much same functionality.
Making contact easier is a worthy goal, but security.txt seems the wrong way to go about it.
and problem solved!
Isn't this the same as every company being told to maintain a securityissues@domain email? That will not be subject to any more spamming that maintaining a security.txt email (after all, if anyone knows your domain they can retrieve your security.txt and get the email address). In addition, this may enable people to err "test" the website. If they get caught, they may claim it was so they can report findings.
A better process might be for companies to register with nationally recognized vulnerability disclosure databases that list CVEs. If someone finds a vulnerability they could report it with the national vulnerability database acting as a middle man. Let those guys do the legwork of finding the contact. If a company doesn't have a contact easily discoverable or registered with the vuln database too bad .. the vuln will get published after 30 days.
Yes, lets put a plain text file on the same file system that could be compromised by hackers containing the contact info to report security risks.... Its not like the first thing a hacker would do is change this file to point to a BS address so that no one gets notified...... (oh and people will be able to harvest all these addreses as w ell).....
Most of the time I'm looking for a wtf.txt
if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue.
This is based on the false assumption that websites actually care about security. 99.9% of all companies couldn't care less, as proven by the almost daily occurrence of breaches.
Here's a better idea:
Put the security.txt above the server's Document Root. That way you'd actually have to hack/exploit the server to get at the security contact's information.
1. The WHOIS database normally carries an abuse email address. 2. This does SFA for port scans, email abuse or other abuses not hosted on an web server.
Can I create a default in my .wgetrc file to ignore security.txt the same as I can ignore robots.txt?
Sounds like a new way to spear-phish the most important IT people.
Robots.txt is the reason why so many fucking web sites are lost forever, and can't even be found on archive.org 's Wayback Machine
>:(
how about whois + dns - oh wait we already have it
Shouldn't there be a !DONTHACKMEBRO! directive?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Step 1. Add a file security.txt to your web server containing your contact information.
Draft itself has an obvious security hole.
Section 4:
" As stated in Section 2.4, keys specified using the "Encryption:" directive SHOULD be loaded over HTTPS."
There is no suggestion anywhere in the draft security.txt be served over a secure transport rendering section 4 suggestion for reference to public key be secure moot.
Security directive 1: Do not hack this site.
Security directive 2: obey all security directives
This should be added to the DNS so it shows in the whois contact list on other sites, not on a server which may be down or replaced.
So, just like DNS records then?
Don't most domains have a webmaster@domain email address for things like this any more?
The problem is that they don't want to hear about it. You want to see some change? Promote whichever existing security advisory system is most ruthless about disclosure, and send everyone there to announce everything they discover.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I hope this gets update to comply with RFC 5785. There are far too many people inventing "special" URLs at the root level of sites, which are likely to clash with pages that already exist. RFC 5785 says that such URLs should be like http ://example.org/.well-known/security.txt instead of http ://example.org/security.txt . That way, they won't clash with existing pages. RFC 5785 also defines a registry for these URLs, to avoid the situation where two specs define different meanings for the same URL.
Whats wrong with the abuse record in the WHOIS?