> The aim is that, for example, ethical hackers can immediately contact the right person or department to tackle the vulnerability.
We added such a file years ago. There's still some security researchers ("bug hunters") not aware of the standard and email other email addresses (info@, invoice@, data-protection@). Nobody has ever used the GPG key we list in the security.txt file. The email address we list (security@) hasn't received any significant spam.
I've reported some bugs and one thing that I always hate is the GPG Key. It is always a huge hassle to use for some reason and for half of the time it doesn't even seem correct or the other party isn't even using it themselves anymore.
If you are an average person and you notice that changing the ID in the URL to another number gives you access to data you should not see; you aren't some elite hacker as many of the news articles try to portray you. So expecting from them to use a GPG Key while they only have their ISP provided webmail will be near impossible for them to do under half a days work.
Especially as most GPG tools are very unfriendly to use.
Just yesterday there was a thread here, where a random user was added as admin for multiple accounts for GCP accidentally, and he couldn't talk to a human on Google to get it resolved. He was neither actively looking out for nor was not anything other than the average user.
OP is correct PGP, is a hassle, and needs explicit knowledge to use it correctly.
Keybase somewhat solved it then got unpopular, but thinking about it again even Keybase never went mainstream.
While I wouldn't call it "mainstream", Keybase got a lot of computer-literate but not IT people into PGP, which hasn't really happened before. It had a good chance to go mainstream, but I guess this ending was inevitable since it was a for-profit company after all...
I understand that the average Joe isn't going to be using pgp. But the kind of folks that go looking for a security.txt file will be able to figure it out.
I think email is a good standard that you can safely assume will be there for the forseeable future. Many communication platforms come and go, email staied thare from Internet's beginning to today and shows no sign of disappearing. Plus you can safely assume that a person on the Internet has at least one email account (exeptions are extremely rare, often is even your ISP that gives you an email account), the same doesn't hold true for other plarforms like Discord.
Interesting - I guess I didn't get "significant" spam either, but after a dozen or so beg bounties I had enough of it and removed it again. And now it's back to roughly zero beg bounties. Serious security researchers won't have a hard time clicking "Contact" in my website header & sending an e-mail to that address anyways.
Honestly, I at least glance at the beg bounties, but they're all so formulaic and bullshit it's easy to see what's up.
Once I was getting too many to glance at, hard to say. Probably mailing a physical letter to the address of record (if it's not a company and so has no address, not sure).
Just report the issue honestly, don’t try to obfuscate, and don’t send a message to a security@ with something like “I found a security issue” with no details of any kind.
If it’s not a security@ and not specifically listed as a security point of contact it’s fair to ask if it’s the right location for a potentially security-sensitive issue and whether there’s a better one.
these are probably the people more interested in getting someone to sign off on a bug bounty than they are in getting hold of someone technical who might point out that the fact you can right click and edit the HTML to say "HACKED!!" isn't a bug...
A lot of people just don't care about writing to the right address. I did work for a university and the most random people would get emails aimed at completely different departments, staff or even a different university. I don't mean old people or clueless young students, I mean some press contacts, some other academics and people like that.
I very recently had a 'dont care about the write address' story -- which I think is worth remember for those of us that monitor some of these less-common but known-to-technical-people mailboxes....
When I had an issue with LastPass, the ONLY contact method they listed for support required you to log in and use their help form...
Since I used federated login, only the browser extension was supported -- not website login... So.. I can't log into their website for support, but I have to log into their website for support...
I went through a series of help@ support@ helpdesk@ contact@ and got bounces / "use our web form" responses... I then escalated to the other technical addresses like webmaster@ hostmaster@ until I finally tried to reach out to sales@ for the support issue...
So sometimes people do intentionally write to 'the wrong address' because there's no 'right address' (that's publicly known/available).
I'm skeptical that GPG encryption is really useful for such reports anyway. Any attacker with access to important email addresses that would receive such reports probably already has a higher level of access than whatever is being reported. And in the case of bug reports, I don't think being able to verify the sender is all that important.
The purpose of publishing your [company’s] public key is not only to verify the sender. It gives the sender a way to send an encrypted email that only the recipient can read (as long as they still have the key pair.)
Based on the limited public PGP key infrastructure, OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message. Being as certificates have to be renewed frequently and verified people would most likely have up-to-date keys.
Level of effort is roughly a one line openssl command for both encryption and decryption.
* I suppose though one thing I didn't consider is follow up messages or correspondence which using PGP would be easier, if everything is already working in your email client. Although it wouldn't be that difficult to include your public key in the initial message, which could be used for responding.
Is there a bit more you can expand on this? A contact form only serves one-way communication and if its sending an email anyway what is the workflow improvement or additional confidentiality/integrity with regards to the message?
The workflow i'm thinking of would be encrypting text with the public key of the website/company you are reaching out to, including your public key in the message or if you have a website as a researcher you can provide the instructions of using your public key for them to send you a response. You then send them an email and attached your encrypted correspondence.
When they respond back they use whatever public key you provided in your initial message and you can decrypt their response. This doesn't require your email client to support PGP or have a keyring setup just simple openssl command(s) that work right from the terminal.
The original goal post was for the original sender to confidentially send a message to the website owners.
> OpenSSL would seem to be the better solution for this. You already have the companies public key from the site certificate and it provides the same confidentiality and integrity since only their private key would be able to decrypt the message.
So a simple form over HTTPS achieves the security researcher -> company part. I agree that it's not sufficient on its own for a confidential two way communication channel, but it can also be achieved over the same technologies. But maybe implementing a messaging platform for the sole purpose of reporting security issues is overkill and could bring its own attack surface.
Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption. You might as well just put up a messaging dialog at a dedicated security endpoint that is accessible through the browser and let the researcher reuse the same messaging session in some robust way for an effective two-way secure communication channel (login, client certificate).
Yeah I was having the same thought on the web form and if it brings additional overhead maintenance, testing, etc which to me would be the same as trying to get some form of PGP working across mail clients.
> Having said that, if the problem is the limited PGP infrastructure then I don't see how an ad-hoc protocol that uses the same certificates as the site's HTTPS cert is going to get more adoption.
This is the only part I would disagree with and it could be subjective based on your experience with certificates. Using openssl wouldn't really be ad-hoc as this is what certificates are for. If the researcher and the website owner already have certificates for their websites there isn't any other additional work as both public keys are available in the form of their site certificates. There are also a number of sites that provide instructions on generating self-signed certificates [1][2][3] as well as encrypting messages with public certs [4][5][6].
Oddly enough when looking for the (3) openssl commands for encrypting a message I came across this site which recommended using GPG for messages[4], however they all pre-suppose that you have everything setup for using GPG which usually isn't the case and using openssl, in my opinion, has reduced friction being as it doesn't depend on being integrated into a web or email client application, you can simply attach the generated encrypted message like any other email attachment.
The infrastructure concern is really the existing public key availability, accessibility and maintenance options for keys. If the public service is unreliable or lacking robustness then both software developers and individuals are less likely to use or integrate the implementation. There are only a few places to upload your pgp key to that are reliable, compared to the existing certificate system. On my last looking there were maybe (3) sites that were reliable[7] and MIT had been flaky for a while, leaving only two.
However, to your initial point I can certainly see a web interface being a better overall solution as the people set to receive these notifications may not be familiar with the command line or terminal interfaces let alone openssl commands.
Thanks for your response I enjoyed thinking through this.
I understand that. But I also said that I don't think encrypting the message has much of a benefit. I can't imagine many scenarios where a compromised email address would be less of a threat then reading the messages sent to that account.
A security researcher finds a server-side RCE vulnerability and discloses it to security@bigcorp.net. An attacker breaks into security@bigcorp.net because the password was the IT director's dog's name.
Don't you think being able to read that disclosure would give the attacker a bit more access to bigcorp's systems than if it was encrypted?
You must be joking! Do you store all your SSH keys in your email? Do IT directors in big companies even have shell access to production servers? Even if, that would show in the audit logs, whereas an RCE is less likely to. And what if the bug is client-side??
They wouldn't have to have access or SSH keys. The position is usually at a level where people don't question requests or have a heightened guard with emails. It wouldn't be difficult to pivot to requesting an account made for some project or including an attachment that compromises a device which you have phone home. This is shown a number of times publicly with phishing emails that lead to breaches, gift cards scams and wire fraud.
In your proposed situation having access to the director of IT's email account is similar to physical access on a server. The RCE might be another layer of access but its not game changing to what is already available.
To get an idea of how well our government organisations get along with implementing this (and a lot of other basic security requirements, like TLS, IPv6, DNSSEC, etc) you can view these maps[0][1].
We maintain a set of open source tools to easily get you started[2]. If you would like help to have this for your country/government/organisation as well, feel free to contact us.
Is there an enforcement arm? As in, what if some agency decides not to do it for some reason - do they get sanctioned in any way? In the US Federal government, there are two I'm familiar with: budget and dragging agency heads in front of congress or the Executive Office and yelling at them. The first doesn't always work - cutting the budget of an important agency over what the press would call a "minor IT issue" doesn't look good (and counter productive). The second tends to work better.
Central government can force any covered entity to publish which standards they (do not) support, to produce an audit, and in the last instance, instruct them to comply. This is a specific provision on top of generic rules and regulations, where central government can step in the place of a lower government if they are non-compliant.
Also, citizens (or NGOs) can sue entities (including central government) for non-compliance. For example, in 2022, the NGO Urgenda won a case against the Dutch government for not doing enough about climate change (less than needed to comply with international treaties), and now the political landscape is in turmoil because there's no consensus which polluters should stop polluting quite as much.
In practice, the list of standards is just tacked onto procurement procedures. Since governments and contractors love to bicker, a missing security.txt can be something to hit the vendor over the head with (and withhold payment for a month, to make this year's budget).
edit: W're a small team and we can't allocate the time needed to make that repo decently public atm. For now it's best to drop an email at the adres found here [0] and I'll help you get along.
Ooh, I've been wanting to do this for India for a long time. Got around to domain lists [1], [2], but never got around to publishing my scan reports. Will reach out.
This has been discussed to death every time security.txt comes up, but in my experience it's been a great way to receive spam about bullshit "vulnerabilities" from low effort scanners operated by "security researchers".
Much like how people publish email addresses online using human readable replacements (e.g. AT instead of @) to avoid spam, I'd rather put up a contact page that's easy for humans to find but nontrivial to automate.
Most of those are trivial to filter. Mentioning SPF or DKIM -> straight to the bin. Contains "critical" and "payment" -> straight to the bin. There's few patterns you'll find that will let you remove all the beg bounties.
> Contains "critical" and "payment" -> straight to the bin.
That sounds like an excellent way to accidentally filter out serious vulnerabilities. I'm glad you don't work for the vendor that received my urgent, critical (in all caps) unauthenticated remote code execution vulnerability report.
They were very grateful that I reached out and resolved it under 72h.
Did you write "I found critical vulnerability on your website, how much is your bounty, can you send PayPal payment?"
If it wasn't something close to that, then no, it wouldn't be filtered. If it wasn't obvious, the patterns are trivial, but not "check those two words" level of trivial. You need to apply common sense and adjust for your environment.
Yep I have received a genuine report completely unsolicited before, paid a modest bounty and fixed the problem immediately, then took some precautions to ensure any potential data leaks were rendered innocuous.
I was very glad to have received the info and I think folks such as yourself are doing valuable work.
Hint for applying ideas from comments: read information and understand the main point behind it, consider how it applies to your situation, then if it's beneficial try to implement it in a way relevant to you.
If you take comments like mine and try to implement them literally, that's stupid and it's on you.
Depending on your application, setting up SPF and DKIM can be complicated. And typically not having it set up is not a security issue, it may affect deliverability of your outgoing email, but is not a vulnerability.
(and indeed many beg bounties are about SPF or DKIM, because whatever automated tools they use to find the low hanging fruit didn't find anything more substantial).
Of course it's a security issue, because having neither SPF nor DKIM means that malicious actors can all too easily impersonate your email addresses and phish users with an email that apparently came from your domain.
I occasionally get what I'm sure are very well meaning SPF/DKIM-missing reports for a domain that has a null mx record.
It can basically be assumed that anyone trying to report that didn't do even a basic cursory look at the results. I don't need your automated scan, I have my own nessus deployment and already know what it's going to say.
"null record" is not "no record". It's an MX record of priority "0" and value "."
No MTA will try to deliver a message that is from or to a domain that has a null record. If you're the sender, your sending MTA might give you an NDR, but receiving infrastructure will just drop it.
Cloudflare actually has a wizard that implements it in addition to the items on the page you linked. And no offense to whoever wrote the CF article, but they are the new kids on the block relative to email.
> Null MX does nothing to prevent spoofing. It is just to signal to mail senders that your domain does not receive email.
And I also found multiple other sources that specify that the null record only announces that the domain does not receive email. After some googling I didn't find a single source that shares your explanation.
A large chunk of the beg bounty reports I see are "critical: your SPF is misconfigured, we'd like to share the details with you, how much are you paying".
2.5.6. Hiring
The "Hiring" field is used for linking to the vendor's security-related job positions. If this field indicates a web URI, then it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]).
Because you care about privacy and other people knowing you're looking at the job postings?
Because you don't want a man in the middle modifying the job ad to say "must be 7 feet tall to apply"?
And finally because security should be the default unless there is a good reason to do it some other way. It's a bit like having an unpainted car because you're going to drive it in dry places where it won't rust... Unless there is a benefit to an unpainted car, most people take the painted car...
An unsecure http GET could be modified and redirect the interested person to a fake site, even if the original target would do nothing but redirect to its https-variant.
I am not sure why it's relevant whether methods are supported by GUI browsers at all (please refer to URIs by method, not "protocol"); because the security.txt is likely to be parsed automatically (since it is, of course, not HTML) and indeed, "tel:" and "mailto:" are both somewhat apt methods to be invoked by a company who's hiring/receiving reports, and doesn't want/need a website for it.
So yeah, it is important that this part of the RFC specify a difference between "web" and "non-web" URIs, because the authors of security.txt are free to use any URI method that makes sense.
SFTP (sort-of-FTP over SSH) was never browser supported afaik.
I'm not sure about FTPS (FTP over SSL/TLS), did browsers support it when they supported regular FTP?
Interesting implication that the field can contain a non-web URI. I just imagine seeing a `file://` URI and the application procedure is to somehow get your CV onto their server.
As a recent college grad, I was struggling to find job interviews this
year and decided to be a bit creative. I scoured Google for humans.txt files containing job openings, and discovered a couple of relevant
ones, such as Expensify's (https://www.expensify.com/humans.txt) and my favorite from Tumblr (https://www.tumblr.com/humans.txt). Expensify even got back to me for an interview!
My hope is that one of these days, I will stumble upon a company that hides secret job openings in their .plan files - accessible through the finger protocol (https://en.wikipedia.org/wiki/Finger_(protocol)) :)
See: "finger @lsc.mit.edu" and "finger seattle@graph.no" for some examples.
Keep in mind this is only mandatory for government websites. That's a pretty low bar. If I worked for the government, or even a company that had one clear way to contact security, I would love this. I honestly have no fucking idea how to directly contact security most of the time and that's insane because I actually want to help them.
I don't care if they receive spam, I just want them to tell me how to contact them. Give me a captcha form, a phone number, an AOL Instant Messenger handle, I don't care.
"Dutch government websites must comply with the security.txt standard from 25 May. This is announced by the Digital Trust Center of the National Government."
You are looking in the wrong place. https://securitytxt.org/ proposes to create a text file called security.txt under the .well-known directory of your project.
It's "well known" if you've manually set up SSL certs for a site using certbot. But yea I agree it's a weird choice to put it there instead of the same place as humans.txt, robots.txt and etc.
Iirc “they” decided that all new standards for “specific URLs you may want to serve for a particular purpose” will be under /.well-known. Robots is grandfathered because it’s super old and established and thus crazy to move. There won’t be anymore “at the root” standards.
Au contraire, it's the other way around. It makes more sense to put favicon.ico, robots.txt and humans.txt in .well-known, but that's life, these files are legacy. (shrugs)
We've always been strongly influenced by our big three neighbors (UK, France and Germany). I remember reading somewhere that before WW2 France was our biggest "cultural influencer" (for example, we spelled helicopter "hélicoptère", until the Canadians liberated us). It's probably not surprising that WW2 made German less popular, and the Anglosphere more popular afterwards.
I traveled in southern France for a bit and it seems to me like it could be a Paris/Quebecois thing because I found a "STOP" (no "ARRÊT" on it anywhere) sign at an intersection in about as rural an area you can get. Granted, sample size is small, but there do seem to be gradients even inside France.
That's because France like many other countries, but not Canada, signed an international treaty that standardizes road signs: https://en.wikipedia.org/wiki/Vienna_Convention_on_Road_Sign... That makes it a bit easier to drive safely across countries without reading all local languages.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
# Domeinen van de Rijksoverheid kunnen met een 302 redirect verwijzen naar
# het centrale bestand op https://www.ncsc.nl/.well-known/security.txt
# omdat het NCSC het centrale meldpunt is voor kwetsbaarheden en incidenten
# voor de Rijksoverheid.
#
# Dutch central government domains can redirect to the central file located
# at https://www.ncsc.nl/.well-known/security.txt with a 302 redirect,
# because NCSC-NL is the central point of contact for vulnerabilities and
# incidents for the Dutch central government.
Expires: 2024-01-31T22:59:00.000Z
Canonical: https://www.ncsc.nl/.well-known/security.txt
Policy: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Policy: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
Contact: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Contact: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
Contact: mailto:security@ncsc.nl
Encryption: https://www.ncsc.nl/contact/pgp-key
Preferred-Languages: nl, en
Acknowledgments: https://www.ncsc.nl/wall-of-fame
Hiring: https://www.werkenvoornederland.nl
-----BEGIN PGP SIGNATURE-----
Version: Encryption Desktop 10.4.2 (Build 1298)
Charset: utf-8
wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6v
YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG0pA
B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJvhxq8
mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOoWvS6SRX
KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuazc5iynhhih
+ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC
2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ
wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq
lNVMWzOncidAWM0nXcuYTjZagRAagthF
=yC4A
-----END PGP SIGNATURE-----
Version: Encryption Desktop 10.4.2 (Build 1298)
Charset: utf-8
Oh for sure, I'm sitting on a subdomain takeover at a pretty large company, I tried looking for an appropriate email or place to report it, found none so I just went the support route without any luck, just said they "will share it with the appropriate team", I've had control for over 2 months now.
I’m working on a simple website generator for developers and content creators.
I’ve already included everything a user would want for a complete website, including a robots.txt, sitemaps, perfect Lighthouse seo score, rich snippets, and a ton of other stuff.
Should I consider adding an auto generated security.txt file along side the robots.txt file for users?
Do you’all think a security.txt file is something users would want in 2023? Or would it look stupid and confusing?
IMO, including those generated .txt files is a small[ish] feat that's important to those that are looking for it, and benign to those that don't need it or know what it is.
I suspect most users who use a site generator would be happy with more "automagic"—especially if it were 1. easy to config or turn off and 2. addressing important things like security-related contact info, or how a web-scraping bot should respect your domain.
Also: "simple" generators often veer into "complicated" territory by adding crap features. Elegant appears to lack crap features; IMO, adding *.txt would not complicate or confuse.
Hey thank you for the kind words!! No crap features here :)
We have started with a basic clean foundation, and are now in the process of building up all the essential features an app owner would want, and none of the crap they wouldn't lol.
Never heard about security txt files until now, but it makes a lot of sense!
Regulations are a hit or miss (e.g the cookie notification rules have some good parts but I wonder if there isn't any room for improvement in the current "visiting a website for 10 seconds and clicking whatever the big button is so that I see the content in interested in" status quo.
This one is not obtrusive, easy to implement (though only developers care about this part) and solves the problem.
The government making rules for its own subdivisions is different from those other regulations that constrain what private third parties can do.
The linked article explicitly mentions that they _hope_ private companies will adopt this standard; but there's no mention of any regulatory requirement on them.
Heard of it, but I’m still wondering why every RFC looks like it’s from 1998. We work with structured data all the time.
Then I remembered the armistice between yaml and toml and how I’m still confused about why the python community was torn asunder.
(lol. One looked like python to devs on mac/linux, and one looked like python to windows users who used INI a lot. Only a true scotsman uses plaintext, HTTP-style)
There’s a lot of history involved, and a difference between authoring and publication formats. It’s only comparatively recently (2016–2019, can’t remember exactly and can’t be bothered looking it up) that they stopped having the canonical form of the published document being monospace plain text with fixed pagination. Now, it’s markup, and so it can readily be presented in quite different ways. Observe this security.txt RFC 9116 formatted in two different ways:
This is a win for GPG. Some, like the current PyPI maintainers, want to throw it out with no replacement. That's a terrible idea. And I don't see why it needs to be replaced completely.
The "Acknowledgments" field indicates a link to a page where security researchers are recognized for their reports. The page being referenced should list security researchers that reported security vulnerabilities and collaborated to remediate them. Organizations should be careful to limit the vulnerability information being published in order to prevent future attacks.
If this field indicates a web URI, then it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]).
Really appreciated this article - it's high time the Dutch government websites took steps like these towards strengthening their security! Still, they could definitely do with a bit more user-friendly explanations, so everyone can understand the importance of initiatives like security.txt.
Unless there's a way to mandate that the security team's contacts listed in security.txt actually respond in a timely manner to security-related messages that are sent to them, then I have a nagging feeling that:
* well-run organizations won't benefit from doing this, since their security teams were already easy to reach
and
* poorly-run organizations won't become any better by doing this, because one text file doesn't fix a broken org
This measure is useful, but only if there are people answering the phone/email/etc that understand how to deal with the report - ie. security folks. In many places, they will just add the contact of some administrative assistant that has no concept of security and no options to deal with the report.
Well most domain names have an abuse email address attached. I emailed a few that belonged to (presumably) compromised hosts sending spam and had no reply and no change in spam volumes. These types of measures are only useful if acted upon.
Similar experience here. Years ago I got emails from Mozilla for a few days in a row about failed login attempts to my account from a certain IP. I did a WHOIS on that and I obtained that it belonged to Fastweb, it was likely some household's dynamic IP. I emailed the listed Fastweb's abuse email address a couple of times, but never got any reply. The login attempts stopped, but I would say probably because whoever was doing it figured out they weren't able to guess my password, not because Fastweb actually did something about it.
We added such a file years ago. There's still some security researchers ("bug hunters") not aware of the standard and email other email addresses (info@, invoice@, data-protection@). Nobody has ever used the GPG key we list in the security.txt file. The email address we list (security@) hasn't received any significant spam.