13 ms·

Security.txt

705 points by janvdberg 9y ago

peterwwillis 9y ago
....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
- jsmthrowaway 9y ago
  > If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything. Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's originating from you; if you are catching spam to abuse@ or postmaster@, well, do the math. abuse@, postmaster@, security@ and friends are discussed in RFC 2142, with a couple "must" directives that are important: > However, if a given service is offerred [sp], then the associated mailbox name(es) must be supported, resulting in delivery to a recipient Emphasis mine. https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt
  - otp124 9y ago
    This is great information! Slightly off topic, but I’m curious about your username. Why have you kept on using a throwaway for all of these years?
  - mjw1007 9y ago
    Reading all mail to postmaster@ has been utterly impractical for many years.
    - jsmthrowaway 9y ago
      If you're one person with a vanity domain, maybe. If you're running a business that operates mail, it's mandatory.
      - mjw1007 9y ago
        abuse@: yes. postmaster@: no. If people have trouble contacting a business by email, they don't try to use email to fix the problem. They very sensibly go to the web site and try by phone or Twitter or some other medium that isn't the one that isn't working.
        jsmthrowaway 9y ago
        postmaster@ exists for many, many more reasons than non-deliverability. Again, multiple RFCs dictate its existence and management. Advice to the contrary demands a better rationale than you're providing, and is ill-advised. If you operate SMTP and I can't get through to you on postmaster@ ("yo, back off your retries," for example), I'm probably going to blacklist you. I'm not unique in the slightest. The decentralized nature of SMTP demands that I have a hotline to you, the MX operator, without having to navigate a Web site to maybe find you.
        mjw1007 9y ago
        Deliverability problems may be caused by misconfigured spam filters. Over-aggressive retries won't be. So I see no justification there for paying staff to manually filter postmaster@ spam.
        _jal 9y ago
        I always try postmaster@ first, when reporting mail problems. Unfortunately, I'd guess that ~75% of the domains I try to contact about that don't have it. (And only slightly better with abuse@, for that matter.) And then there are the shops who seem to believe that sending mail from bad addresses and publishing no public email addresses for anything is cool. I'm not fond of this solution, but have started considering them spammers and blocking them entirely. (I don't particularly care about them - if they want to send email to my systems they can put their big-pants on and join the rest of the responsible operators; I just don't like seeing services balkanizing like this.)
  - Dylan16807 9y ago
    > if you are catching spam to abuse@ or postmaster@, well, do the math. Well... the most recent time I've seen abuse@ mentioned, it was Hetzner looking at fake IPs on DDoS traffic and spamming abuse complaints at the wrong people. https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banned_from_discord/dn2tuam/ https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banne...
    - jsmthrowaway 9y ago
      Hetzner is a long-running social experiment to frustrate other Internet network administrators trying to hail it on all frequencies, so that sort of thing doesn't surprise me. We should all be better actors on the Internet, as this thread underscores, and it's just too bad you sound like you're wearing a sandwich board when you advocate for it. The incentives don't line up with running a business, much like with IPv6 and BCP38. It'd be cool if we could throw RADb, PeeringDB, RFC 2142 contacts, WHOIS data, the routing table, courtesy phones, spam blacklists, and all the other tools available to administrators in a blender and come up with a nice, centralized way to instant message the right person with root at another Internet company for any possible scenario from any possible identifiable resource involved in the Internet without having to possess the tribal knowledge you pick up after doing it a while. Such a facility doesn't line up with the decentralized nature of the Internet, which is why I think it hasn't happened yet. How would you talk people into using it, too? There's a critical mass problem. I've always wanted to build exactly that thing, but I fear nobody would use it. Until that exists, it's important to watch your abuse mailboxes. Only point I'm making. The Internet moves fast.
  - kuschku 9y ago
    So much this. I recently ran a port scan of a subset of the internet on a single port. (To get an estimate how many servers with a certain old protocol version were still running, as I wanted to drop it from a client I was working on) I previously messaged the contact email given by the AS of every affected subnet. I got over 4 weeks not a single complaint or request to be excluded. Then I did the scan, and got tons of complaints – and once I pointed out the email I sent them, most got very quiet, but one continued to complain and tell me I should have tried harder to contact them.
    - jlgaddis 9y ago
      I work for an ISP and mails for abuse@ and friends end up in my mailbox. Occasionally, there's a "legit" one that I need to look into but the majority of them are automatically-generated reports that some IP address in our netblocks port scanned them or something stupid. The first one gets ignored, the second one usually gets a response from me to the effect of "please stop sending us these automated notifications", and the third one gets the sending mail server's IP address added to my local blacklists. My favorite ones to ignore are from a company who allegedly represents Viacom, Warner Bros., TNT, etc., keeping me up to date on what our customers are torrenting.
rando444 9y ago
A section for acknowledgements? Also the Contributions AKA "these random accounts from twitter may have participated to the project to some degree, but we don't want to disclose their names or contributions" section of the website made me smile.
- woodrowbarlow 9y ago
  according to the IETF draft, the acknowledgements directive is meant to point to a page thanking people who have discovered and reported vulnerabilities in the past. doesn't seem very useful to me. since the document supports comments, just put that link in a comment.
lifeisstillgood 9y ago
I seem to remember suggesting jobs.txt as a listing for a company’s open positions. Someone even made a site promoting the idea. What I mean to say is that the concept of a domain is much deeper than html, and we use it so shallowly. The web is distributed and simple if we want it back.
- Top19 9y ago
  Can you expand more on this? What do you mean by “much deeper than html”?
  - libeclipse 9y ago
    He means if you have a domain you can pretty much serve whatever you want off of it.
    - lifeisstillgood 9y ago
      Maybe html was wrong phrase. I mean the distributed nature as typified by everyone having their own domain - with attached storage. This was the default back in the dial up days (side thought is that Apple could bring that back - iCloud is nice as storage and all but how much will it take to go from iCloud to paulsdomain.com/photojournal - that’s almost a Facebook killer and at some point is much much easier to distribute)
- cujic9 9y ago
  That's interesting. I love the idea of sites exposing various types of data through plain text files with well-known names. Kind of like (a vastly simplified) RSS feed, but for whatever. Or something vaguely like Gopher sites, back in the day. But then, the company would want to brand it, and the marketing team would want to track views, and the sales team would want some kind of call to action, and the product managers would want to make it cross platform and internationalized. And suddenly we're back at something that looks like HTML. sigh
ejcx 9y ago
Ive only done security in SaaS in my career. This text file is pretty useleas. Disclosure is very out of place, and indicates to me that it's pretty much just for companies with a bug bounty I'm a bit negative, but I don't want more useless emails from security researchers. Companies that do security well will adopt this, and are already easy to get ahold of...
mjw1007 9y ago
Should surely be .well-known/security.txt, or if not explain why not. rfc5785 "Defining Well-Known Uniform Resource Identifiers (URIs)" [edit: I see the FAQ says that, while the linked Internet Draft says it goes at top-level like robots.txt]
- baby 9y ago
  Ahhh. That explains why lets encrypt does it!
  - gerdesj 9y ago
    There's also Netscape's (?) email autodiscover mechanism with a .xml file served from there that describes how to do POP/IMAP/SMTP etc. However, despite /.wellknown/ being a bit of a standard, you'd be amazed at how many mechanisms you have to support to get autodiscover to work for all email clients. As it turns out SRV DNS records are also a bit of a standard for publishing pointers to services, and TXT records, and RANDOMLY_NAMED_RECORDS because updating your server n resolver to support another record type is such fun. I actually think we are almost there now: DNS to find it and /.wellknown/ to describe it.
    - Spivak 9y ago
      SRV records are extremely popular outside of the web. I really wish they would get more adoption. It's such a clean solution. We could have avoided the entire need for SNI if browsers supported service records.
      - gerdesj 9y ago
        I love SRV records but they are really just TXT with an API! PTR is A in a weirdly named domain ... SNI avoidance is a weird one and you are probably right but SNI is only important (hah!) if you consider that we should all be using IPv6 by now and have billions of address per host to play with 8) The rest of the world gets uptight about TLDs but there is one - relating to ENUM - that no one seems to mention and get upset about. If they did, instead of crapping on about whether Brazil or a US company owned "amazon" for example, then I'll give you (nearly) free telephone calls and a load of big Telcos will implode. Except they wont and the world will move on to the next logical step where all internet connections are no longer considered a sub-function of a telephone connection and the notion of a "leased line" is an anomaly. Whoops, got carried away there. As you say - SRV should get more love.
fbnlsr 9y ago
I think humans.txt (http://humanstxt.org/ http://humanstxt.org/) fits more, and already exists.
- irrational 9y ago
  I've never heard of this. I wonder how many websites implement this. I tried a bunch of sites, but the only one I could find that had a humans.txt file was google: Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us out, see google.com/careers.
  - r3bl 9y ago
    Here's two examples: https://medium.com/humans.txt https://medium.com/humans.txt, https://www.python.org/humans.txt https://www.python.org/humans.txt.
  - darkhorn 9y ago
    https://www.google.com/humans.txt https://www.google.com/humans.txt
  - erichurkman 9y ago
    We do: https://esharesinc.com/humans.txt https://esharesinc.com/humans.txt It's part of every new engineer's first day or two. It's their first shipped PR to add themselves as a human.
  - JosephRedfern 9y ago
    I do! https://redfern.me/humans.txt https://redfern.me/humans.txt It should really be human.txt...
    - Deimorz 9y ago
      A redirect to LinkedIn definitely isn't a proper implementation.
Aaron1011 9y ago
I can't seem to find a definition of "Partial disclosure" on either the website or the IETF RFC draft.
- gregmac 9y ago
  Yeah, I was looking for the same. All the draft [1] says is: 2.5. Disclosure: Specify your disclosure policy. This directive MUST be a disclosure type. The "Full" value stands for full disclosure, "Partial" for partial disclosure and "None" means you do not want to disclose reports after the issue has been resolved. The presence of a disclosure field is NOT permission to disclose vulnerabilities and explicit permission MUST be saught where possible. In contrast, the actual generator tool on the website uses a URL (https://example.com/disclosure.html https://example.com/disclosure.html) as a placeholder, which doesn't comply with this section. [1] https://tools.ietf.org/html/draft-foudil-securitytxt-00#section-2.5 https://tools.ietf.org/html/draft-foudil-securitytxt-00#sect...
  - tedunangst 9y ago
    Explicit permission must be saught (sic)? How does that work?
    - tptacek 9y ago
      It doesn't even make sense if you assume the terms are defined, because disclosure obligations are bilateral. If I'm reporting a bug to your site because I've found a new ImageMagick vulnerability, it is more likely that I the reporter want an embargo from you the site operator than the other way around.
jph 9y ago
If you're considering this, please consider responsible disclosure steps. Here are ones I use with consulting clients. https://github.com/joelparkerhenderson/responsible_disclosure https://github.com/joelparkerhenderson/responsible_disclosur...
- tptacek 9y ago
  Please consider replacing the term "responsible disclosure" with "coordinated disclosure", and revise your steps accordingly. Non-coordinated disclosure isn't necessarily "irresponsible", and the suggestion that it is is frowned upon among serious testers, which are presumably the ones you want to attract with disclosure policy. And it's worth remembering that any kind of disclosure "policy" is a request for a favor from the researcher, so it's good to word things accordingly. You wouldn't generally ask for a concession (like honoring an embargo on publicly reporting a finding you took time to generate) right after also "asking" the reporter to report "in good faith".
  - jph 9y ago
    Done. Thank you for the advice, and all your security work. https://github.com/joelparkerhenderson/coordinated_disclosure https://github.com/joelparkerhenderson/coordinated_disclosur... If you have anything more you want in it, please let me know.
    - jpswade 9y ago
      Isn't responsible disclosure the aim here? I don't think substituting coordination for responsible is a sensible strategy for your project. The coordination is inherit from the fact that they are honouring your disclosure policy. The word coordinated is redundant. Objectively, it should be called a "security disclosure" policy.
      - jph 9y ago
        You make good points. How would you improve it to clarify the aim is to be generally useful for both sides? For example, when I personally discover a security issue, I want to be able to report it to a company, and also include a link to this doc, and ask "Here's how I suggest we interact and why; what do you think?".
ikeboy 9y ago
If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.
- s17n 9y ago
  Enables automated vulnerability disclosure.
  - BillinghamJ 9y ago
    Nobody wants this. Automated disclosure means getting even more automated-scan reports. Total waste of time.
  - JetSpiegel 9y ago
    The data behind this is not machine readable anyway, what's the gain here?
- thephyber 9y ago
  The more you use a Google feature as a crutch, the less the web is semantic. Also, Google has increasingly made it difficult to automate searches, so the effort required to notify multiple websites increases quickly.
  - r3bl 9y ago
    > Also, Google has increasingly made it difficult to automate searches That's an understatement. Doing something as simple as inurl:"humans.txt" ...and consuming the first three pages showed me CAPTCHA. It was done via a browser, manually. Not all links were clicked.
    - mad182 9y ago
      Yep, I run across this often. Kind of funny that using a bit more advanced functionality instantly makes you suspicious.
dreamdu5t 9y ago
As an operator of many websites... I don't want more emails from "Security Researchers" who want $100 to tell me the obvious such as, "Login form should be rate-limited" or "emails can be enumerated using password reset form" and the like... Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before contacting the software owner prior to disclosure.
- IncRnd 9y ago
  > Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before contacting the software owner prior to disclosure. There are plenty of those. Generally, they take a cut of the bounty.
- bzbarsky 9y ago
  On the flip side, such a vulnerability repository may not have incentives aligned with either the bug reporter or the software owner. See https://palant.de/2017/10/04/observations-on-managed-bug-bounty-programs https://palant.de/2017/10/04/observations-on-managed-bug-bou... for a recent post about that sort of problem.
bkeroack 9y ago
The first thing every attacker will do: replace security.txt
- dmix 9y ago
  Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites... Changing things is how you get detected. Much like that recent thread where John Kelly brought his phone in to IT because it wouldn't update and they found malware. That's an obvious failure in any "APT" hackers guide. This isn't like modifying .bash_history to hide malicious behaviour (or worse removing command auditing entirely when it's a potential company/personal policy to activate it on all machines).
  - jlgaddis 9y ago
    > Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites... Yet, for many, many years, that was probably the most common thing that attackers (including a much younger, teenaged version of yours truly) did. At that time, however, "defacing" web sites was done mostly for bragging rights and without malicious intent. In many (most?) cases, the original index.html page would be copied/backed up and the "new" web page (created haphazardly using vi, perhaps) would replace or augment it. For a long time, there were even mirrors [0] of these defaced web pages. attrition.org ran one from 1995-2001 and, for much of that time, even ran a mailing list where they would announce these "defacements" -- often, immediately after they occurred (after being tipped off by the attackers). It was pretty common to be able to view the "still defaced" site while it was still live (before being taken down and/or restored). As a frame of reference, attrition.org stopped mirroring these sites in May 2001 [1]. > ... it will no longer mirror the defacements because keeping up with the volume and rate of hacks is too much work ... ([1]) So, yeah, it happened A LOT. It is, of course, a much different world now (although defacements still occur regularly). [0]: http://attrition.org/mirror/ http://attrition.org/mirror/ [1]: https://www.computerworld.com/article/2582627/security0/attrition-org-stops-mirroring-web-site-defacements.html https://www.computerworld.com/article/2582627/security0/attr...
pg_is_a_butt 9y ago
so i should abandon my /return-policy.txt standard? you're all idiots.
IncRnd 9y ago
This site is horribly complex for creating a plain-text file with four fields. Perhaps, the complexity comes from having 10 contributors. _Not everything needs to be a large project._ A template right on the webpage would have the same value. That raises the point that a blog post about the RFC would have greater utility.
- hw 9y ago
  There are people out there who spend the time and effort to create a good looking site, even for something as simple as generating a plain text file with 4 fields. Your comment would have greater utility if it was actually about the subject of the site itself, and not about how it was designed.
  - IncRnd 9y ago
    That's a fair point. In practicality, I don't see a need for this .txt file to be present. There are other .txt files, such as humans.txt, that don't have widespread adoption, due to lack of generated value. While there are many issues inherent in reporting vulnerabilities, this .txt file will not solve them. Not only is the file's existence error-prone from a maintenance perspective, but my experience has shown me that such a file is not needed. Due to these factors, I believe that the existence of such a file is unwarranted complexity without a corresponding level of benefit.
libeclipse 9y ago
Nice idea, but a little inconsistent. Even their own site doesn't comply with their own RFC.
- jopsen 9y ago
  Yeah, the RFC seems very vague too. I could see some value in meta-data for automated reporting of security issues. But the spec would have to be less informal.
deleted 9y ago
[deleted]
korzun 9y ago
It took seven people to make a useless static file generator? Bandwagon security.
snakeanus 9y ago
A bit sad that it does not allow for the file to be signed with OpenPGP.
- jlgaddis 9y ago
  What precludes you from including a comment with a link to the signed version of the file with ".asc" appended to the filename?
  - cyphar 9y ago
    Nothing, but then it's an extension to a spec for a five-line plaintext file. Seems quite wasteful.
jacquesm 9y ago
https://securitytxt.org/.well-known/security.txt https://securitytxt.org/.well-known/security.txt Gives a 404 but https://securitytxt.org/security.txt https://securitytxt.org/security.txt Has the file... maybe they should either follow their own advice or update the text of the advisory? Like this it appears a bit inconsistent.
- TheSwordsman 9y ago
  Per the Draft RFC `security.txt` is meant to be akin to `robots.txt`, in that it's at the root of the path. So yeah, it's a bit inconsistent.
  - jacquesm 9y ago
    That is going to cause some problems with a very large percentage of webservers being configured to never allow the fetching of any dotfiles to avoid accidentally exposing stuff that wasn't meant to be in the web tree in the first place.
    - raimue 9y ago
      /.well-known/ is defined in RFC5785 and paths under this prefix can be registered with IETF. For example, /.well-known/acme-challenge/ is used by ACME, the domain verification protocol used by Let's Encrypt. https://www.ietf.org/rfc/rfc5785.txt https://www.ietf.org/rfc/rfc5785.txt It should not be too hard to make an exception for this path in your web server configuration. Also note that URLs do not have to match the local filesystem, so you could as well use an alias to a different local path.
- ehsankia 9y ago
  Also, the contact is a twitter instead of an email, doesn't that break the whole reason for this, which is being able to automate it to some extent?
- theandrewbailey 9y ago
  Seems to be fixed?
unixhero 9y ago
Should have a section for which software license the website code is under Also for any runtime JavaScripts And should alsonspecofy how private data is stored And how private data is collected, processed and for how long it is retained
- cyphar 9y ago
  > Should have a section for which software license the website code is under LibreJS already has standardised ways for websites to report this, which are far more flexible and useful.
stefanwlb 9y ago
Heh I thought the domain ending was "txt" and was trying to register domain with ".txt" before I relised that it doesn't exist and that it's securitytxt.org and not secuirty.txt ! Silly me
tptacek 9y ago
I don't think this is fully baked. Most importantly: there are no formal definitions for what these disclosure terms mean, the distinctions between them are not unimportant, and the most important distinctions have nothing at all to do with "disclosure". To me, as a working professional in this field, "disclosure: full" informs me that if I report a vulnerability in your service, you'll publish some sort of public advisory, or agree to me doing so, on my own timeline, regardless of when you're fully patched and regardless of whether you've confirmed or triaged the bug. Is that exactly your understanding of "disclosure: full"? If not, there's your first minor problem. But there's more important problems. Actually, I don't need any permission whatsoever to publish a vulnerability I find in your site, nor is there any real norm in the infosec community that I shouldn't ("responsible disclosure" is a meme propagated by vendors who want to control independent researchers). You can state your preference that I coordinate with you ("coordinated disclosure" is the researcher-friendly way to write "responsible disclosure"), but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude. But that's still not the big problem. The BIG problem is that disclosure policy has nothing to do with whether you can test. There is a widespread belief on the US Internet that light web application testing of SaaS products is allowed. It is very much not. Without explicit permission to test a website I put on the Internet, your doing so violates (and probably should violate!) CFAA, and in some states also state statutes. That goes not just for disruptive testing, like seeing if you can break a SQL query, but also for stuff that most testers believe is harmless, like light XSS testing. I can't tell you how many times an XSS test vector "broke" a site for a client, for instance when it got cached as a "recent search" and displayed, in a DOM-breaking way, to every user on the home page for the site. Bring down a site like that without permission, and even if it says "disclosure: full", you might be civilly liable for the downtime. I think the "disclosure" field here is thus pretty ill-advised. It advertises a policy that isn't super useful for researchers to know, and doesn't define the most important policy, which is "am I allowed to test this site and what are the rules of engagement for doing so". What does that leave us with? A PGP key and the name of your security email address. The PGP key is useful, but the contact address should just always be "security@" anyways. There's really no need for a standard format for this stuff. Just create a "security.html" or whatever that reminds people to send mail to security@, publishes your PGP (note to Symantec: public key) key, and gives people permission to test the site. Update One of the authors DM'd me to say they're removing "Disclosure" from the next version of the draft, which is I think the right move.
dsacco 9y ago
Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone number and the last four digits of their credit card to a public QSR company that allows online orders. It was straightforward enough that I found it passively while trying to login. It took over a week of me searching the website for a security page, trying to contact support on Twitter, emailing security addresses that turned out to be undeliverable, looking through my network for a contact, etc. Someone with a better network than me finally put me in touch with the right person in the security org, and the first response I received was, essentially, "Are you trying to sell us something? This seems manipulative. Why didn't you email our [undeliverable] address?" As far as I'm aware, the vulnerability still hasn't been resolved. Here are the problems I see: 1. I don't know if this is a good implementation of this idea in the first place - how does this handle liability? I agree with what tptacek mentioned in this thread already: this seems underspecified, and companies looking to adopt this will want to have specific assurances with regards to liability and what's allowed. What exactly does "Disclosure Type: Full" mean? 2. If a company is not already in the tech trendy group that like to host security pages and use bug bounties, this is probably not even going to be on their radar. What is different about this that will appeal to them? How do you get a large, faceless organization which regards its security organization as more of a risk/compliance/continuity division than a technical software security division to adopt this standard? To be clear, as someone who has gone through this song and dance several times, I absolutely would like to see improvements. But I don't know that this is the best way to do it. A more realistic standard might be a central tracker that maintains a list of key security contacts and their email addresses at various organizations. There are already lists like this floating around on GitHub, but they tend to be extremely out of date. Other than that it would be helpful to try and standardize a /security.html page with details about who and where to contact (instead of, say, a page that assumes every customer looking for a security contact mistakenly believes their accounts have been "hacked").
- freedomben 9y ago
  This is utterly maddening. I had a similar experience, except that at first they didn't believe me regarding the vulnerability. I basically said, "cool, I'm glad it's not a problem, so when I release the deets and write up a blog post you have nothing to worry about ;-)" After they finally acknowledged the problem they started treating me like I was a criminal who attacked them. I strictly follow responsible disclosure, but it's crap like that that makes me want to reconsider sometimes.
disconnected 9y ago
This is just "feel-good" bullshit that doesn't actually solve any real problem. In my life, I have only reported two different vulnerabilities to two different vendors. One of them didn't care at all. They were transmitting usernames and passwords in plaintext and I actually showed one of their engineers this, live, in person, and he just shrugged. The other one told me something to the effect of "yes, this is very serious. We'll look into it right away" and actually fixed it... 3 years later. Your biggest hurdle isn't reporting vulnerabilities. That's the easy part. The biggest hurdle is getting someone to care.
- subcosmos 9y ago
  >In my life, I have only reported two different vulnerabilities to two different vendors. Interesting. I don't think this is for you. Ever have the task of needing to report a security issue to 10k sites and wish you could have any hope of automating it? I certainly haven't. More like 100k! Don't be so negative when people try to do good.
  - manigandham 9y ago
    You needed to contact 100k sites about security? Do you have more details on this? The example security.txt for this site currently has a twitter handle as the contact. How are you going to automate that?
    - mzzter 9y ago
      One may want to notify many website owners at once that it’s a good time to apply a patch in response to a security vulnerability affecting a technology they are using. Ex: WordPress, node.js, MongoDB, etc.
      - manigandham 9y ago
        There are 100s of millions of sites, who’s going to crawl all of them and send out alerts? How would you know what backend tech is being used? Major risks and CVEs are already published in the appropriate news channels, which is far more efficient and effective.
pg_is_a_butt 9y ago
Maybe if you contacted the liability lawyers first, they would have the power to force the fix. Maybe if there was a standard security.txt file that would cc the lawyers on all reports, the lawyers would force the standard to be used, and thus your biggest hurdle is solved. your post was "feel-bad" bullshit that was much worse. you're all idiots.
hitekker 9y ago
This entire page reads as a stream of consciousness. This one line is particularly egregious: "Security.txt defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities." > Defines a X to help Y define a Z for Q to W. > Securely close security vulnerabilities. Ick.
manigandham 9y ago
This is completely useless. Any company that cares about security enough to do this will already have security@, support@, abuse@ emails setup. Those are the well known contact endpoints. Bug bounty platforms also have contact info and messaging built-in.
- 2bitencryption 9y ago
  what RFC describes that standard?
  - btown 9y ago
    Well, common sense for one, but also https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt section 4!
  - jlgaddis 9y ago
    cf. RFC2142
- freedomben 9y ago
  I agree that any company that cares about security already has the emails setup, however I don't think it's completely useless. So many companies really don't know what they don't know regarding security. Easy digestable steps can be helpful. But I agree that in practice 95% of companies won't give a crap about this and therefore won't do anything with it.
askvictor 9y ago
So when a site is hacked, the hackers replace the email and public key in this file with their own (or one that goes to /dev/null), and the site's owners are never informed when someone else notices the breach and tries to use this file as intended. There should either be a well known convention (like security@ as others hadn't mentioned), or an external public registry of this sort of thing)
- solatic 9y ago
  Because it's a standardized text file in a standard location, it's quite easy to add a black box monitor of the file and alert if the values change. If anything, mucking around with the file is the last thing hackers want to do, because it would tip off the operators that there had been a breach, that the operators otherwise would not have noticed.
  - askvictor 9y ago
    Good points, though those should be spelt out in the original document/site
hannob 9y ago
Whether or not such a file makes sense is another question, but I find the mentality of the "Disclosure" field quite puzzling. It is not up to an affected party to decide what disclosure terms apply. After responsibly disclosing an issue to a site a security bug finder should disclose it to the public, whether the affected site likes that or not.
aauthespian1 9y ago
http://www.aauthespian.news/2017/10/new-music-johnbosco-bubbles-up-prod-by.html http://www.aauthespian.news/2017/10/new-music-johnbosco-bubb...
accurrent 9y ago
I smell an opportunity for spam bots.
campuscodi 9y ago
Here's my interview with Ed on the IETF proposal: https://www.bleepingcomputer.com/news/security/security-txt-standard-proposed-similar-to-robots-txt/ https://www.bleepingcomputer.com/news/security/security-txt-...
kseifried 9y ago
Suggested for policy inclusion for CNA (CVE Numbering Authority) guidelines. And yes, I would suggest they remove the disclosure policy, it's not really all that germane for the vendor, from the security researchers point of view. Edit: forgot link: https://github.com/CVEProject/docs/issues/53 https://github.com/CVEProject/docs/issues/53
vectorEQ 9y ago
how about just put the right address in whois information??? >.> ... if you gonna put it on the public internet anyhow might aswell use the age old mechanism already in place to do this...
- tmdvs 9y ago
  I don't understand why businesses use use private WHOIS services. Surely if you're a business you'll have public contact information? I was once tasked with trying to get in touch with a company who's domain name had expired, but with no website (read: contact page) or real email address in the WHOIS I had to give up.

705 points by janvdberg 9y ago

....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.

jsmthrowaway 9y ago
> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything. Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's originating from you; if you are catching spam to abuse@ or postmaster@, well, do the math. abuse@, postmaster@, security@ and friends are discussed in RFC 2142, with a couple "must" directives that are important: > However, if a given service is offerred [sp], then the associated mailbox name(es) must be supported, resulting in delivery to a recipient Emphasis mine. https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt
- otp124 9y ago
  This is great information! Slightly off topic, but I’m curious about your username. Why have you kept on using a throwaway for all of these years?
- mjw1007 9y ago
  Reading all mail to postmaster@ has been utterly impractical for many years.
  - jsmthrowaway 9y ago
    If you're one person with a vanity domain, maybe. If you're running a business that operates mail, it's mandatory.
    - mjw1007 9y ago
      abuse@: yes. postmaster@: no. If people have trouble contacting a business by email, they don't try to use email to fix the problem. They very sensibly go to the web site and try by phone or Twitter or some other medium that isn't the one that isn't working.
      - jsmthrowaway 9y ago
        postmaster@ exists for many, many more reasons than non-deliverability. Again, multiple RFCs dictate its existence and management. Advice to the contrary demands a better rationale than you're providing, and is ill-advised. If you operate SMTP and I can't get through to you on postmaster@ ("yo, back off your retries," for example), I'm probably going to blacklist you. I'm not unique in the slightest. The decentralized nature of SMTP demands that I have a hotline to you, the MX operator, without having to navigate a Web site to maybe find you.
        mjw1007 9y ago
        Deliverability problems may be caused by misconfigured spam filters. Over-aggressive retries won't be. So I see no justification there for paying staff to manually filter postmaster@ spam.
      - _jal 9y ago
        I always try postmaster@ first, when reporting mail problems. Unfortunately, I'd guess that ~75% of the domains I try to contact about that don't have it. (And only slightly better with abuse@, for that matter.) And then there are the shops who seem to believe that sending mail from bad addresses and publishing no public email addresses for anything is cool. I'm not fond of this solution, but have started considering them spammers and blocking them entirely. (I don't particularly care about them - if they want to send email to my systems they can put their big-pants on and join the rest of the responsible operators; I just don't like seeing services balkanizing like this.)
- Dylan16807 9y ago
  > if you are catching spam to abuse@ or postmaster@, well, do the math. Well... the most recent time I've seen abuse@ mentioned, it was Hetzner looking at fake IPs on DDoS traffic and spamming abuse complaints at the wrong people. https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banned_from_discord/dn2tuam/ https://www.reddit.com/r/discordapp/comments/70dwa6/ip_banne...
  - jsmthrowaway 9y ago
    Hetzner is a long-running social experiment to frustrate other Internet network administrators trying to hail it on all frequencies, so that sort of thing doesn't surprise me. We should all be better actors on the Internet, as this thread underscores, and it's just too bad you sound like you're wearing a sandwich board when you advocate for it. The incentives don't line up with running a business, much like with IPv6 and BCP38. It'd be cool if we could throw RADb, PeeringDB, RFC 2142 contacts, WHOIS data, the routing table, courtesy phones, spam blacklists, and all the other tools available to administrators in a blender and come up with a nice, centralized way to instant message the right person with root at another Internet company for any possible scenario from any possible identifiable resource involved in the Internet without having to possess the tribal knowledge you pick up after doing it a while. Such a facility doesn't line up with the decentralized nature of the Internet, which is why I think it hasn't happened yet. How would you talk people into using it, too? There's a critical mass problem. I've always wanted to build exactly that thing, but I fear nobody would use it. Until that exists, it's important to watch your abuse mailboxes. Only point I'm making. The Internet moves fast.
- kuschku 9y ago
  So much this. I recently ran a port scan of a subset of the internet on a single port. (To get an estimate how many servers with a certain old protocol version were still running, as I wanted to drop it from a client I was working on) I previously messaged the contact email given by the AS of every affected subnet. I got over 4 weeks not a single complaint or request to be excluded. Then I did the scan, and got tons of complaints – and once I pointed out the email I sent them, most got very quiet, but one continued to complain and tell me I should have tried harder to contact them.
  - jlgaddis 9y ago
    I work for an ISP and mails for abuse@ and friends end up in my mailbox. Occasionally, there's a "legit" one that I need to look into but the majority of them are automatically-generated reports that some IP address in our netblocks port scanned them or something stupid. The first one gets ignored, the second one usually gets a response from me to the effect of "please stop sending us these automated notifications", and the third one gets the sending mail server's IP address added to my local blacklists. My favorite ones to ignore are from a company who allegedly represents Viacom, Warner Bros., TNT, etc., keeping me up to date on what our customers are torrenting.

rando444 9y ago

A section for acknowledgements? Also the Contributions AKA "these random accounts from twitter may have participated to the project to some degree, but we don't want to disclose their names or contributions" section of the website made me smile.

woodrowbarlow 9y ago
according to the IETF draft, the acknowledgements directive is meant to point to a page thanking people who have discovered and reported vulnerabilities in the past. doesn't seem very useful to me. since the document supports comments, just put that link in a comment.

lifeisstillgood 9y ago

I seem to remember suggesting jobs.txt as a listing for a company’s open positions. Someone even made a site promoting the idea. What I mean to say is that the concept of a domain is much deeper than html, and we use it so shallowly. The web is distributed and simple if we want it back.

Top19 9y ago
Can you expand more on this? What do you mean by “much deeper than html”?
- libeclipse 9y ago
  He means if you have a domain you can pretty much serve whatever you want off of it.
  - lifeisstillgood 9y ago
    Maybe html was wrong phrase. I mean the distributed nature as typified by everyone having their own domain - with attached storage. This was the default back in the dial up days (side thought is that Apple could bring that back - iCloud is nice as storage and all but how much will it take to go from iCloud to paulsdomain.com/photojournal - that’s almost a Facebook killer and at some point is much much easier to distribute)
cujic9 9y ago
That's interesting. I love the idea of sites exposing various types of data through plain text files with well-known names. Kind of like (a vastly simplified) RSS feed, but for whatever. Or something vaguely like Gopher sites, back in the day. But then, the company would want to brand it, and the marketing team would want to track views, and the sales team would want some kind of call to action, and the product managers would want to make it cross platform and internationalized. And suddenly we're back at something that looks like HTML. sigh

ejcx 9y ago

Ive only done security in SaaS in my career. This text file is pretty useleas. Disclosure is very out of place, and indicates to me that it's pretty much just for companies with a bug bounty I'm a bit negative, but I don't want more useless emails from security researchers. Companies that do security well will adopt this, and are already easy to get ahold of...

mjw1007 9y ago

Should surely be .well-known/security.txt, or if not explain why not. rfc5785 "Defining Well-Known Uniform Resource Identifiers (URIs)" [edit: I see the FAQ says that, while the linked Internet Draft says it goes at top-level like robots.txt]

baby 9y ago
Ahhh. That explains why lets encrypt does it!
- gerdesj 9y ago
  There's also Netscape's (?) email autodiscover mechanism with a .xml file served from there that describes how to do POP/IMAP/SMTP etc. However, despite /.wellknown/ being a bit of a standard, you'd be amazed at how many mechanisms you have to support to get autodiscover to work for all email clients. As it turns out SRV DNS records are also a bit of a standard for publishing pointers to services, and TXT records, and RANDOMLY_NAMED_RECORDS because updating your server n resolver to support another record type is such fun. I actually think we are almost there now: DNS to find it and /.wellknown/ to describe it.
  - Spivak 9y ago
    SRV records are extremely popular outside of the web. I really wish they would get more adoption. It's such a clean solution. We could have avoided the entire need for SNI if browsers supported service records.
    - gerdesj 9y ago
      I love SRV records but they are really just TXT with an API! PTR is A in a weirdly named domain ... SNI avoidance is a weird one and you are probably right but SNI is only important (hah!) if you consider that we should all be using IPv6 by now and have billions of address per host to play with 8) The rest of the world gets uptight about TLDs but there is one - relating to ENUM - that no one seems to mention and get upset about. If they did, instead of crapping on about whether Brazil or a US company owned "amazon" for example, then I'll give you (nearly) free telephone calls and a load of big Telcos will implode. Except they wont and the world will move on to the next logical step where all internet connections are no longer considered a sub-function of a telephone connection and the notion of a "leased line" is an anomaly. Whoops, got carried away there. As you say - SRV should get more love.

fbnlsr 9y ago

I think humans.txt (http://humanstxt.org/ http://humanstxt.org/) fits more, and already exists.

irrational 9y ago
I've never heard of this. I wonder how many websites implement this. I tried a bunch of sites, but the only one I could find that had a humans.txt file was google: Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us out, see google.com/careers.
- r3bl 9y ago
  Here's two examples: https://medium.com/humans.txt https://medium.com/humans.txt, https://www.python.org/humans.txt https://www.python.org/humans.txt.
- darkhorn 9y ago
  https://www.google.com/humans.txt https://www.google.com/humans.txt
- erichurkman 9y ago
  We do: https://esharesinc.com/humans.txt https://esharesinc.com/humans.txt It's part of every new engineer's first day or two. It's their first shipped PR to add themselves as a human.
- JosephRedfern 9y ago
  I do! https://redfern.me/humans.txt https://redfern.me/humans.txt It should really be human.txt...
  - Deimorz 9y ago
    A redirect to LinkedIn definitely isn't a proper implementation.

Aaron1011 9y ago

I can't seem to find a definition of "Partial disclosure" on either the website or the IETF RFC draft.

gregmac 9y ago
Yeah, I was looking for the same. All the draft [1] says is: 2.5. Disclosure: Specify your disclosure policy. This directive MUST be a disclosure type. The "Full" value stands for full disclosure, "Partial" for partial disclosure and "None" means you do not want to disclose reports after the issue has been resolved. The presence of a disclosure field is NOT permission to disclose vulnerabilities and explicit permission MUST be saught where possible. In contrast, the actual generator tool on the website uses a URL (https://example.com/disclosure.html https://example.com/disclosure.html) as a placeholder, which doesn't comply with this section. [1] https://tools.ietf.org/html/draft-foudil-securitytxt-00#section-2.5 https://tools.ietf.org/html/draft-foudil-securitytxt-00#sect...
- tedunangst 9y ago
  Explicit permission must be saught (sic)? How does that work?
  - tptacek 9y ago
    It doesn't even make sense if you assume the terms are defined, because disclosure obligations are bilateral. If I'm reporting a bug to your site because I've found a new ImageMagick vulnerability, it is more likely that I the reporter want an embargo from you the site operator than the other way around.

jph 9y ago

If you're considering this, please consider responsible disclosure steps. Here are ones I use with consulting clients. https://github.com/joelparkerhenderson/responsible_disclosure https://github.com/joelparkerhenderson/responsible_disclosur...

tptacek 9y ago
Please consider replacing the term "responsible disclosure" with "coordinated disclosure", and revise your steps accordingly. Non-coordinated disclosure isn't necessarily "irresponsible", and the suggestion that it is is frowned upon among serious testers, which are presumably the ones you want to attract with disclosure policy. And it's worth remembering that any kind of disclosure "policy" is a request for a favor from the researcher, so it's good to word things accordingly. You wouldn't generally ask for a concession (like honoring an embargo on publicly reporting a finding you took time to generate) right after also "asking" the reporter to report "in good faith".
- jph 9y ago
  Done. Thank you for the advice, and all your security work. https://github.com/joelparkerhenderson/coordinated_disclosure https://github.com/joelparkerhenderson/coordinated_disclosur... If you have anything more you want in it, please let me know.
  - jpswade 9y ago
    Isn't responsible disclosure the aim here? I don't think substituting coordination for responsible is a sensible strategy for your project. The coordination is inherit from the fact that they are honouring your disclosure policy. The word coordinated is redundant. Objectively, it should be called a "security disclosure" policy.
    - jph 9y ago
      You make good points. How would you improve it to clarify the aim is to be generally useful for both sides? For example, when I personally discover a security issue, I want to be able to report it to a company, and also include a link to this doc, and ask "Here's how I suggest we interact and why; what do you think?".

ikeboy 9y ago

If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.

s17n 9y ago
Enables automated vulnerability disclosure.
- BillinghamJ 9y ago
  Nobody wants this. Automated disclosure means getting even more automated-scan reports. Total waste of time.
- JetSpiegel 9y ago
  The data behind this is not machine readable anyway, what's the gain here?
thephyber 9y ago
The more you use a Google feature as a crutch, the less the web is semantic. Also, Google has increasingly made it difficult to automate searches, so the effort required to notify multiple websites increases quickly.
- r3bl 9y ago
  > Also, Google has increasingly made it difficult to automate searches That's an understatement. Doing something as simple as inurl:"humans.txt" ...and consuming the first three pages showed me CAPTCHA. It was done via a browser, manually. Not all links were clicked.
  - mad182 9y ago
    Yep, I run across this often. Kind of funny that using a bit more advanced functionality instantly makes you suspicious.

dreamdu5t 9y ago

As an operator of many websites... I don't want more emails from "Security Researchers" who want $100 to tell me the obvious such as, "Login form should be rate-limited" or "emails can be enumerated using password reset form" and the like... Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before contacting the software owner prior to disclosure.

IncRnd 9y ago
> Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before contacting the software owner prior to disclosure. There are plenty of those. Generally, they take a cut of the bounty.
bzbarsky 9y ago
On the flip side, such a vulnerability repository may not have incentives aligned with either the bug reporter or the software owner. See https://palant.de/2017/10/04/observations-on-managed-bug-bounty-programs https://palant.de/2017/10/04/observations-on-managed-bug-bou... for a recent post about that sort of problem.

bkeroack 9y ago

The first thing every attacker will do: replace security.txt

dmix 9y ago
Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites... Changing things is how you get detected. Much like that recent thread where John Kelly brought his phone in to IT because it wouldn't update and they found malware. That's an obvious failure in any "APT" hackers guide. This isn't like modifying .bash_history to hide malicious behaviour (or worse removing command auditing entirely when it's a potential company/personal policy to activate it on all machines).
- jlgaddis 9y ago
  > Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites... Yet, for many, many years, that was probably the most common thing that attackers (including a much younger, teenaged version of yours truly) did. At that time, however, "defacing" web sites was done mostly for bragging rights and without malicious intent. In many (most?) cases, the original index.html page would be copied/backed up and the "new" web page (created haphazardly using vi, perhaps) would replace or augment it. For a long time, there were even mirrors [0] of these defaced web pages. attrition.org ran one from 1995-2001 and, for much of that time, even ran a mailing list where they would announce these "defacements" -- often, immediately after they occurred (after being tipped off by the attackers). It was pretty common to be able to view the "still defaced" site while it was still live (before being taken down and/or restored). As a frame of reference, attrition.org stopped mirroring these sites in May 2001 [1]. > ... it will no longer mirror the defacements because keeping up with the volume and rate of hacks is too much work ... ([1]) So, yeah, it happened A LOT. It is, of course, a much different world now (although defacements still occur regularly). [0]: http://attrition.org/mirror/ http://attrition.org/mirror/ [1]: https://www.computerworld.com/article/2582627/security0/attrition-org-stops-mirroring-web-site-defacements.html https://www.computerworld.com/article/2582627/security0/attr...

pg_is_a_butt 9y ago

so i should abandon my /return-policy.txt standard? you're all idiots.

IncRnd 9y ago

This site is horribly complex for creating a plain-text file with four fields. Perhaps, the complexity comes from having 10 contributors. _Not everything needs to be a large project._ A template right on the webpage would have the same value. That raises the point that a blog post about the RFC would have greater utility.

hw 9y ago
There are people out there who spend the time and effort to create a good looking site, even for something as simple as generating a plain text file with 4 fields. Your comment would have greater utility if it was actually about the subject of the site itself, and not about how it was designed.
- IncRnd 9y ago
  That's a fair point. In practicality, I don't see a need for this .txt file to be present. There are other .txt files, such as humans.txt, that don't have widespread adoption, due to lack of generated value. While there are many issues inherent in reporting vulnerabilities, this .txt file will not solve them. Not only is the file's existence error-prone from a maintenance perspective, but my experience has shown me that such a file is not needed. Due to these factors, I believe that the existence of such a file is unwarranted complexity without a corresponding level of benefit.

libeclipse 9y ago

Nice idea, but a little inconsistent. Even their own site doesn't comply with their own RFC.

jopsen 9y ago
Yeah, the RFC seems very vague too. I could see some value in meta-data for automated reporting of security issues. But the spec would have to be less informal.

deleted 9y ago

[deleted]

korzun 9y ago

It took seven people to make a useless static file generator? Bandwagon security.

snakeanus 9y ago

A bit sad that it does not allow for the file to be signed with OpenPGP.

jlgaddis 9y ago
What precludes you from including a comment with a link to the signed version of the file with ".asc" appended to the filename?
- cyphar 9y ago
  Nothing, but then it's an extension to a spec for a five-line plaintext file. Seems quite wasteful.

jacquesm 9y ago

https://securitytxt.org/.well-known/security.txt https://securitytxt.org/.well-known/security.txt Gives a 404 but https://securitytxt.org/security.txt https://securitytxt.org/security.txt Has the file... maybe they should either follow their own advice or update the text of the advisory? Like this it appears a bit inconsistent.

TheSwordsman 9y ago
Per the Draft RFC `security.txt` is meant to be akin to `robots.txt`, in that it's at the root of the path. So yeah, it's a bit inconsistent.
- jacquesm 9y ago
  That is going to cause some problems with a very large percentage of webservers being configured to never allow the fetching of any dotfiles to avoid accidentally exposing stuff that wasn't meant to be in the web tree in the first place.
  - raimue 9y ago
    /.well-known/ is defined in RFC5785 and paths under this prefix can be registered with IETF. For example, /.well-known/acme-challenge/ is used by ACME, the domain verification protocol used by Let's Encrypt. https://www.ietf.org/rfc/rfc5785.txt https://www.ietf.org/rfc/rfc5785.txt It should not be too hard to make an exception for this path in your web server configuration. Also note that URLs do not have to match the local filesystem, so you could as well use an alias to a different local path.
ehsankia 9y ago
Also, the contact is a twitter instead of an email, doesn't that break the whole reason for this, which is being able to automate it to some extent?
theandrewbailey 9y ago
Seems to be fixed?

unixhero 9y ago

Should have a section for which software license the website code is under Also for any runtime JavaScripts And should alsonspecofy how private data is stored And how private data is collected, processed and for how long it is retained

cyphar 9y ago
> Should have a section for which software license the website code is under LibreJS already has standardised ways for websites to report this, which are far more flexible and useful.

stefanwlb 9y ago

Heh I thought the domain ending was "txt" and was trying to register domain with ".txt" before I relised that it doesn't exist and that it's securitytxt.org and not secuirty.txt ! Silly me

tptacek 9y ago

I don't think this is fully baked. Most importantly: there are no formal definitions for what these disclosure terms mean, the distinctions between them are not unimportant, and the most important distinctions have nothing at all to do with "disclosure". To me, as a working professional in this field, "disclosure: full" informs me that if I report a vulnerability in your service, you'll publish some sort of public advisory, or agree to me doing so, on my own timeline, regardless of when you're fully patched and regardless of whether you've confirmed or triaged the bug. Is that exactly your understanding of "disclosure: full"? If not, there's your first minor problem. But there's more important problems. Actually, I don't need any permission whatsoever to publish a vulnerability I find in your site, nor is there any real norm in the infosec community that I shouldn't ("responsible disclosure" is a meme propagated by vendors who want to control independent researchers). You can state your preference that I coordinate with you ("coordinated disclosure" is the researcher-friendly way to write "responsible disclosure"), but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude. But that's still not the big problem. The BIG problem is that disclosure policy has nothing to do with whether you can test. There is a widespread belief on the US Internet that light web application testing of SaaS products is allowed. It is very much not. Without explicit permission to test a website I put on the Internet, your doing so violates (and probably should violate!) CFAA, and in some states also state statutes. That goes not just for disruptive testing, like seeing if you can break a SQL query, but also for stuff that most testers believe is harmless, like light XSS testing. I can't tell you how many times an XSS test vector "broke" a site for a client, for instance when it got cached as a "recent search" and displayed, in a DOM-breaking way, to every user on the home page for the site. Bring down a site like that without permission, and even if it says "disclosure: full", you might be civilly liable for the downtime. I think the "disclosure" field here is thus pretty ill-advised. It advertises a policy that isn't super useful for researchers to know, and doesn't define the most important policy, which is "am I allowed to test this site and what are the rules of engagement for doing so". What does that leave us with? A PGP key and the name of your security email address. The PGP key is useful, but the contact address should just always be "security@" anyways. There's really no need for a standard format for this stuff. Just create a "security.html" or whatever that reminds people to send mail to security@, publishes your PGP (note to Symantec: public key) key, and gives people permission to test the site. Update One of the authors DM'd me to say they're removing "Disclosure" from the next version of the draft, which is I think the right move.

dsacco 9y ago

Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone number and the last four digits of their credit card to a public QSR company that allows online orders. It was straightforward enough that I found it passively while trying to login. It took over a week of me searching the website for a security page, trying to contact support on Twitter, emailing security addresses that turned out to be undeliverable, looking through my network for a contact, etc. Someone with a better network than me finally put me in touch with the right person in the security org, and the first response I received was, essentially, "Are you trying to sell us something? This seems manipulative. Why didn't you email our [undeliverable] address?" As far as I'm aware, the vulnerability still hasn't been resolved. Here are the problems I see: 1. I don't know if this is a good implementation of this idea in the first place - how does this handle liability? I agree with what tptacek mentioned in this thread already: this seems underspecified, and companies looking to adopt this will want to have specific assurances with regards to liability and what's allowed. What exactly does "Disclosure Type: Full" mean? 2. If a company is not already in the tech trendy group that like to host security pages and use bug bounties, this is probably not even going to be on their radar. What is different about this that will appeal to them? How do you get a large, faceless organization which regards its security organization as more of a risk/compliance/continuity division than a technical software security division to adopt this standard? To be clear, as someone who has gone through this song and dance several times, I absolutely would like to see improvements. But I don't know that this is the best way to do it. A more realistic standard might be a central tracker that maintains a list of key security contacts and their email addresses at various organizations. There are already lists like this floating around on GitHub, but they tend to be extremely out of date. Other than that it would be helpful to try and standardize a /security.html page with details about who and where to contact (instead of, say, a page that assumes every customer looking for a security contact mistakenly believes their accounts have been "hacked").

freedomben 9y ago
This is utterly maddening. I had a similar experience, except that at first they didn't believe me regarding the vulnerability. I basically said, "cool, I'm glad it's not a problem, so when I release the deets and write up a blog post you have nothing to worry about ;-)" After they finally acknowledged the problem they started treating me like I was a criminal who attacked them. I strictly follow responsible disclosure, but it's crap like that that makes me want to reconsider sometimes.

disconnected 9y ago

This is just "feel-good" bullshit that doesn't actually solve any real problem. In my life, I have only reported two different vulnerabilities to two different vendors. One of them didn't care at all. They were transmitting usernames and passwords in plaintext and I actually showed one of their engineers this, live, in person, and he just shrugged. The other one told me something to the effect of "yes, this is very serious. We'll look into it right away" and actually fixed it... 3 years later. Your biggest hurdle isn't reporting vulnerabilities. That's the easy part. The biggest hurdle is getting someone to care.

subcosmos 9y ago
>In my life, I have only reported two different vulnerabilities to two different vendors. Interesting. I don't think this is for you. Ever have the task of needing to report a security issue to 10k sites and wish you could have any hope of automating it? I certainly haven't. More like 100k! Don't be so negative when people try to do good.
- manigandham 9y ago
  You needed to contact 100k sites about security? Do you have more details on this? The example security.txt for this site currently has a twitter handle as the contact. How are you going to automate that?
  - mzzter 9y ago
    One may want to notify many website owners at once that it’s a good time to apply a patch in response to a security vulnerability affecting a technology they are using. Ex: WordPress, node.js, MongoDB, etc.
    - manigandham 9y ago
      There are 100s of millions of sites, who’s going to crawl all of them and send out alerts? How would you know what backend tech is being used? Major risks and CVEs are already published in the appropriate news channels, which is far more efficient and effective.

pg_is_a_butt 9y ago

Maybe if you contacted the liability lawyers first, they would have the power to force the fix. Maybe if there was a standard security.txt file that would cc the lawyers on all reports, the lawyers would force the standard to be used, and thus your biggest hurdle is solved. your post was "feel-bad" bullshit that was much worse. you're all idiots.

hitekker 9y ago

This entire page reads as a stream of consciousness. This one line is particularly egregious: "Security.txt defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities." > Defines a X to help Y define a Z for Q to W. > Securely close security vulnerabilities. Ick.

manigandham 9y ago

This is completely useless. Any company that cares about security enough to do this will already have security@, support@, abuse@ emails setup. Those are the well known contact endpoints. Bug bounty platforms also have contact info and messaging built-in.

2bitencryption 9y ago
what RFC describes that standard?
- btown 9y ago
  Well, common sense for one, but also https://www.ietf.org/rfc/rfc2142.txt https://www.ietf.org/rfc/rfc2142.txt section 4!
- jlgaddis 9y ago
  cf. RFC2142
freedomben 9y ago
I agree that any company that cares about security already has the emails setup, however I don't think it's completely useless. So many companies really don't know what they don't know regarding security. Easy digestable steps can be helpful. But I agree that in practice 95% of companies won't give a crap about this and therefore won't do anything with it.

askvictor 9y ago

So when a site is hacked, the hackers replace the email and public key in this file with their own (or one that goes to /dev/null), and the site's owners are never informed when someone else notices the breach and tries to use this file as intended. There should either be a well known convention (like security@ as others hadn't mentioned), or an external public registry of this sort of thing)

solatic 9y ago
Because it's a standardized text file in a standard location, it's quite easy to add a black box monitor of the file and alert if the values change. If anything, mucking around with the file is the last thing hackers want to do, because it would tip off the operators that there had been a breach, that the operators otherwise would not have noticed.
- askvictor 9y ago
  Good points, though those should be spelt out in the original document/site

hannob 9y ago

Whether or not such a file makes sense is another question, but I find the mentality of the "Disclosure" field quite puzzling. It is not up to an affected party to decide what disclosure terms apply. After responsibly disclosing an issue to a site a security bug finder should disclose it to the public, whether the affected site likes that or not.

aauthespian1 9y ago

http://www.aauthespian.news/2017/10/new-music-johnbosco-bubbles-up-prod-by.html http://www.aauthespian.news/2017/10/new-music-johnbosco-bubb...

accurrent 9y ago

I smell an opportunity for spam bots.

campuscodi 9y ago

Here's my interview with Ed on the IETF proposal: https://www.bleepingcomputer.com/news/security/security-txt-standard-proposed-similar-to-robots-txt/ https://www.bleepingcomputer.com/news/security/security-txt-...

kseifried 9y ago

Suggested for policy inclusion for CNA (CVE Numbering Authority) guidelines. And yes, I would suggest they remove the disclosure policy, it's not really all that germane for the vendor, from the security researchers point of view. Edit: forgot link: https://github.com/CVEProject/docs/issues/53 https://github.com/CVEProject/docs/issues/53

vectorEQ 9y ago

how about just put the right address in whois information??? >.> ... if you gonna put it on the public internet anyhow might aswell use the age old mechanism already in place to do this...

tmdvs 9y ago
I don't understand why businesses use use private WHOIS services. Surely if you're a business you'll have public contact information? I was once tasked with trying to get in touch with a company who's domain name had expired, but with no website (read: contact page) or real email address in the WHOIS I had to give up.