Slashdot Mirror


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

49 of 86 comments (clear)

  1. HTML? by DontBeAMoran · · Score: 3, Informative

    There's going to be <a href>> tags in security.txt? No? Then don't make the links clickable in the fucking summary.

    --
    #DeleteFacebook
    1. Re:HTML? by Anonymous Coward · · Score: 2, Informative

      The Aspergers is strong in this one.

  2. +1 by TFlan91 · · Score: 1

    Hell, I'll be implementing that Monday morning for a couple servers, screw waiting for the standard.

    1. Re: +1 by Monster_user · · Score: 1

      You left a couple of things out: #I'llGetRightOnThat /sarcasm

  3. Spam! by markdavis · · Score: 5, Insightful

    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.

    1. Re:Spam! by wimg · · Score: 2

      Couldn't agree more ! This was exactly what I was thinking : the security contact address will be spammed so hard that it'll be hard to find the mails that should get through.

    2. Re:Spam! by Anonymous Coward · · Score: 5, Funny

      No, the security.txt file will be excluded from crawling via the robots.txt file

    3. Re:Spam! by fahrbot-bot · · Score: 3, Funny

      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.

      Just exclude the "security.txt" file in the "robots.txt" file - problem solved. :-)

      --
      It must have been something you assimilated. . . .
    4. Re:Spam! by jmccue · · Score: 5, Funny

      For US sites, how about adding the Admin's SSN, their address and their Mother's Maiden names ? That way we can really know the file is genuine

    5. Re:Spam! by Anonymous Coward · · Score: 1

      Sounds like http://www.equifax.com/security.txt

  4. Here's my guess... by toonces33 · · Score: 2

    Tools will scour the web to find the contact email addresses, and spam the crap out of them with pitches for various "security" products.

    1. Re:Here's my guess... by Anonymous Coward · · Score: 1

      Yep. Will happen. Besides, unnecessary. Whois entry already has contact info (if it's correct and maintained). If necessary, perhaps a line could be added to the Whois info? And maintenance is the issue: better to have it in one place.

    2. Re:Here's my guess... by iggymanz · · Score: 1

      even worse than that, the goddamn telemarketers will be all over the phone number.

  5. Sure thing by Anonymous Coward · · Score: 1

    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

  6. Re: Please explain the need? by Monster_user · · Score: 1

    Yep, most people who would know the contact the admistrator of the domain would know how to get in touch with the administrator of the domain, who should be competent enough to get the information to a qualified person to rewolve the issue.

  7. P3P redux by Donwulff · · Score: 3, Insightful

    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.

    1. Re:P3P redux by AmiMoJo · · Score: 1

      It's extremely useful. If you see this file with contact details, you know that you have a legal defense if they try to sue you for pointing out their crap security.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:P3P redux by 93+Escort+Wagon · · Score: 1

      It's extremely useful. If you see this file with contact details, you know that you have a legal defense if they try to sue you for pointing out their crap security.

      That's an argument for why you want them to do it, not why they should want to do it.

      --
      #DeleteChrome
    3. Re:P3P redux by AmiMoJo · · Score: 1

      If they care about security it helps them. If they don't, it's absence warns people to do anonymous disclosure.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    4. Re:P3P redux by Donwulff · · Score: 1

      The issue I pointed out wasn't that this wouldn't be useful, but that P3P is a W3C officially recommended protocol/standard started 20 years ago that already does this but much better. However, it never really caught on, and I suspect one main reason is companies don't really want accountability. For the legal defense, the only solution would be a law unequivocally granting immunity if you disclose a vulnerability in responsible manner. A security.txt file isn't worth the paper it's printed on (ie. none) in that regard. I grant P3P is mainly geared towards "privacy" rather than "security", but it does allow specifying the entity in charge as well as any and all dispute-resolution practices, along the intended privacy (Ie. so they don't get flooded by security complaints about showing e-mail addresses when that's intentional, for example).

  8. Example by Artem+S.+Tashkinov · · Score: 2, Funny

    The example.com domain is getting abused again and again. I almost pity its owners.

    1. Re: Example by corychristison · · Score: 3, Informative

      Example.com is owned by IANA.

      This type of example is precisely what example.com is set up for, and is defined in RFC 2606.

  9. Non problem by whoever57 · · Score: 4, Insightful

    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!
    1. Re:Non problem by Actually,+I+do+RTFA · · Score: 1

      On the contrary, standards are super important. If not having a security.txt was considered as negligence by the courts, you'd find many companies needing to add them in order for certifications or to not face crazy damages in the case of a breach. An objective, easy standard like security.txt makes that significantly more likely than anything that requires technical expertise.

      Further, it will lead to standardized/codified standards to respond and cascade in that manner.

      --
      Your ad here. Ask me how!
    2. Re:Non problem by John+Allsup · · Score: 1

      Bang on!

      Security, proper, I mean proper proper, as in 'I say it to my Master, he does not beat me with a stick for being stupid' proper...

      Proper security does not, and cannot, assume that they other lot are abiding by any sort of social convention. Anything less is 'faux security' and, while very marketable, is worse than nothing.

      The only laws hackers must abide by are those of physics and mathematics, and only then when physics and mathematics are done properly.

      --
      John_Chalisque
    3. Re:Non problem by WaffleMonster · · Score: 1

      On the contrary, standards are super important.

      Where I live often seems as if standardizing the size and shape of check boxes is what's most important.

      If not having a security.txt was considered as negligence by the courts

      More likely companies would be afraid to add security.txt for fear its presence represents implicit permission/cover to hack/probe.

      Researchers already face legal risks simply for reporting what they innocently stumble upon. Personally I would only report site vulnerabilities anonymously and probably not even that.

      You'd find many companies needing to add them in order for certifications or to not face crazy damages in the case of a breach.

      My own opinion this is much more likely to end up being yet another joke nobody quite gets like sending an email to abuse@domain and expecting a response.

      Or inventing yet another cache header proclaiming dammit I mean it this time... for real...serious...

    4. Re:Non problem by Actually,+I+do+RTFA · · Score: 1

      My entire point is that ignoring standards ups the "Y" in your story. Literally, that's it. There's not much in that situation that really is likely to change... except X and Y. If something makes those two cross (cheaper security/costlier fines), then that changes the story.

      And, they most certainly can cross. They have in the past for some conditions, and they will again for others in the future.

      --
      Your ad here. Ask me how!
  10. Rewolve? by glitch! · · Score: 3, Funny

    ...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...
    1. Re: Rewolve? by Monster_user · · Score: 1

      Anytime! *resolve*. An iPhone is a pain to create comments on. Autocorrect changes a word to something entirely incorrect, and the editor doesn't highlight typos. Worse, line breaks don't work on Slashdot.

    2. Re: Rewolve? by mrbester · · Score: 1

      Really?

      I've not found line breaks a problem here.

      Ever.

      --
      "Wait. Something's happening. It's opening up! My God, it's full of apricots!"
    3. Re:Rewolve? by glitch! · · Score: 2

      ... And apparently I can't spell lycanthropy correctly the first time.

      --
      A dingo ate my sig...
    4. Re: Rewolve? by Monster_user · · Score: 1

      Yep. Safari on iOS 10. I have line breaks in nearly every post I type. (n \n br
      ) Whenever I view my comments, there is not anline break to be found.

    5. Re: Rewolve? by Monster_user · · Score: 1

      Looks like HTML tags work here.

      Line break.

    6. Re: Rewolve? by Desler · · Score: 2

      Not

      Using

      Line breaks

      Only

      Hitting

      Return.

      Works just fine here on iOS 10 with Safari.

    7. Re: Rewolve? by fisted · · Score: 1

      It's a /. account setting that has nothing to do with where the input comes from.

  11. 20 Years Too Late. Whois Already Exists. by Anonymous Coward · · Score: 3, Insightful

    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.

    1. Re:20 Years Too Late. Whois Already Exists. by Ash-Fox · · Score: 1

      20 years ago this would have been a fantastic idea.

      Wrong. 20 years ago, we would have said "use WHOIS records".

      --
      Change is certain; progress is not obligatory.
  12. Minus 1 for stupidity by Anonymous Coward · · Score: 2, Insightful

    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.

    1. Re:Minus 1 for stupidity by arth1 · · Score: 1

      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.

      It is based on the false assumption that the ones looking up the security.txt file would be people with your best interest in mind, and not spammers and telemarketers who want to sell you security products, or black hats looking for contacts to spearfish.

  13. Better idea by corychristison · · Score: 5, Interesting

    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.

  14. What about the WHOIS database by bib1620 · · Score: 1

    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.

    1. Re:What about the WHOIS database by Anonymous Coward · · Score: 1

      Isn't it obvious? It doesn't involve http so it might as well not exist, as far as "full stack developers" are concerned. Reinventing the wheel badly is what computing is all about.

      Yes, whois was invented exactly for this sort of thing. Indeed, this proposal is in no way an improvement over the existing infrastructure.

      Also, a pox on the editors for linking bleepingcomputer and not the IETF. But this seems to be the gold standard in "web" also.

      Honestly, everyone who does understand what whois is for ought to reach out to the IETF that this is a stupid proposal.

  15. whois? by kiviQr · · Score: 1

    how about whois + dns - oh wait we already have it

  16. Dude ... by Zero__Kelvin · · Score: 1

    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
  17. How to get spammed in one easy step by WaffleMonster · · Score: 1

    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.

  18. So, just like DNS records then? by AC-x · · Score: 1

    So, just like DNS records then?

  19. That's not going to help anything by drinkypoo · · Score: 1

    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.'"
  20. RFC 5785 by jjon · · Score: 1

    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.

  21. Re:Security.txt contents by Ash-Fox · · Score: 1
    --
    Change is certain; progress is not obligatory.