[HN Gopher] Security.txt file now mandatory for Dutch government...
___________________________________________________________________
Security.txt file now mandatory for Dutch government websites
Author : pseudotrash
Score : 339 points
Date : 2023-06-01 09:27 UTC (13 hours ago)
(HTM) web link (netherlands.postsen.com)
(TXT) w3m dump (netherlands.postsen.com)
| punnerud wrote:
| I checked the top 20 most used websites in Germany (with .de),
| and number 20 on the list is the first to have it:
| https://www.focus.de/security.txt
|
| Most used webpages: https://www.similarweb.com/top-
| websites/germany/
| raxxorraxor wrote:
| I think Google suggested a path that was [URL]/.well-
| known/security.txt
|
| Perhaps the sites have something on there.
| punnerud wrote:
| Facebook have the security.txt at root:
| https://facebook.com/security.txt
|
| Both Facebook and Apple also use [URL]/.well-
| known/security.txt
|
| The contact on Facebook don't work:
| https://www.facebook.com/whitehat/report/
| jruohonen wrote:
| I hope other countries follow!
| redleader55 wrote:
| 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.
| jruohonen wrote:
| I agree, but probably still better than nothing?
| gumballindie wrote:
| 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.
| GTP wrote:
| 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.
| fareesh wrote:
| Seems like a vector for phishing / social engineering and
| scammers / advertisers
| aarong11 wrote:
| Quick, find every site with a security.txt and report it /s
| foxbyte wrote:
| 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.
| logifail wrote:
| 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
| qwertox wrote:
| https://www.amsterdam.nl/security.txt returns
|
| ---
|
| Contact: https://www.amsterdam.nl/privacy/informatiebeveiliging-
| gemee...
|
| Expires: 2024-02-01T10:00:00.000Z
|
| Acknowledgments:
| https://www.informatiebeveiligingsdienst.nl/?s=hall+of+fame
|
| Preferred-Languages: en,nl
|
| ---
|
| rfc9116
|
| 2.5.1. Acknowledgments
|
| 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]).
| JohnFen wrote:
| Whatever happened to just having the standard "abuse@domain.name"
| email address?
| aequitas wrote:
| 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.
|
| [0] https://basisbeveiliging.nl/#/metric-
| progress/NL/municipalit... [1] https://basisbeveiliging.nl/#/maps
| [2] https://gitlab.com/internet-cleanup-foundation/web-
| security-...
| captn3m0 wrote:
| 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.
|
| [1]:
| https://gist.github.com/captn3m0/4f3da8f07fe884e62bfab3ac856...
|
| [2]: https://git.captnemo.in/nemo/pulse
| sybercecurity wrote:
| 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.
| bux93 wrote:
| 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).
| Dah00n wrote:
| >If you would like help to have this for your
| country/government/organisation as well, feel free to contact
| us.
|
| I was looking into what exactly is need for this but the last
| link has this in the guide:
|
| >For full installation with everything and anything, check:
| https://gitlab.com/internet-cleanup-foundation/server/
|
| The link is broken.
| aequitas wrote:
| I'm gonna look into that and come back to you.
|
| 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.
|
| [0] https://internetcleanup.foundation/about-us/
| liotier wrote:
| Isn't this what Whois is for ?
| qawwads wrote:
| 1. Find a vulnerability
|
| 2. Contact the website maintainer to report it
|
| 3. Get swatted, harrassed by cops, sued, and jailed over it.
|
| No thank.
| androidas wrote:
| Really cool. I've done responsible disclosure in the past and
| finding someone who'll listen is probably the hardest part of it
| mtmail wrote:
| 20 years ago emailing webmaster@, hostmaster@, abuse@ went
| direct to a tech person. I think these days it's also
| redirected to customer service.
| xdfil wrote:
| [dead]
| chrismorgan wrote:
| Or just rejected--even postmaster@ which is _mandated_ in RFC
| 5321.
| whstl wrote:
| IME sometimes you're lucky and it goes to a product manager,
| but then it is often put in the backlog with 100s other
| tasks.
| KomoD wrote:
| 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.
| mtmail wrote:
| > 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.
| 878654Tom wrote:
| 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.
| the_jesus_villa wrote:
| >Especially as most GPG tools are very unfriendly to use.
|
| Install FlowCrypt (or Mailvelope) and it will become the
| easiest thing in the world. At least, that was my experience!
| mattpallissard wrote:
| > If you are an average person
|
| This isn't for the average person.
| sn_master wrote:
| You're underestimating how many average people or below-
| average hackers find/stumble-upon serious vulnerabilities
| all the time.
| anaganisk wrote:
| 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.
| mattpallissard wrote:
| 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.
| JohnFen wrote:
| Or, more likely, ignore it.
| franga2000 wrote:
| s/got unpopular/acquihired by Zoom and killed/
|
| 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...
| 878654Tom wrote:
| Why not? Many security issues are detected by people who
| just happened to do a series of actions in a way nobody
| expected them to do.
| mywittyname wrote:
| I clicked this "sudo" button and it changed my name in
| the app to "root".
| Zamicol wrote:
| >Is it weird that I expected proof to be a PGP-signed
| message?
|
| >I have not used PGP for many years, because it does not run
| on my iPhone[.]
|
| - Phil Zimmermann, author of PGP
|
| https://old.reddit.com/r/IAmA/comments/x3b3gj
| oneeyedpigeon wrote:
| Even the dependency on email is looking a little outdated --
| at least that's not a requirement of security.txt though.
| GTP wrote:
| 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.
| michaelmior wrote:
| 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.
| jagged-chisel wrote:
| 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.)
| ZeroSolstice wrote:
| 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.
| planede wrote:
| What you propose is basically a form that can be served
| over https.
| ZeroSolstice wrote:
| 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.
| michaelmior wrote:
| 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.
| franga2000 wrote:
| 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?
| blacksmith_tb wrote:
| When the attacker already has the credentials of the IT
| Director? I doubt they will be too interested in bug
| reports, somehow...
| franga2000 wrote:
| 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??
| ZeroSolstice wrote:
| 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.
| Aulig wrote:
| 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.
| abirch wrote:
| Once this goes mainstream I'm betting on massive spam. I'd
| only list the contact us url
| bombcar wrote:
| Beg bounties are getting more and more common.
| hsbauauvhabzb wrote:
| What's the best way to get things read? Prefix them with 'I
| am NOT looking for payment, reward or bounty'?
| galleywest200 wrote:
| Putting that at the front of your email makes it sound
| even more sketchy to me.
| bombcar wrote:
| 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).
| masklinn wrote:
| 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.
| londons_explore wrote:
| > and email other email addresses
|
| 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...
| looping8 wrote:
| 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.
| ldoughty wrote:
| 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).
| NoZebra120vClip wrote:
| 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]).
|
| Hey, I just found a new way to job hunt!
| PMunch wrote:
| 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.
| mcny wrote:
| That is one way to show your commitment to "encourage career
| growth" I guess?
|
| Assuming someone who works at the company would have easier
| access to someone who has access to the server in question...
| Gigachad wrote:
| >If this field indicates a web URI, then it MUST begin with
| "https://"
|
| Or what? What is the point of even specifying this? It's not
| like any human or bot is going to ignore the link if it starts
| with http://
| qwertox wrote:
| 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.
|
| It does make sense.
| thisgoesnowhere wrote:
| I'm convinced the people commenting on this article are
| just contrarians.
|
| "How could you possibly have standards" isn't a very
| interesting conversation yet here we are having it at
| scale.
| GoblinSlayer wrote:
| >An unsecure http GET could be modified and redirect the
| interested person to a fake site
|
| You don't have a threat model, do you?
| justsomehnguy wrote:
| "Beware of the leopard"
| nicce wrote:
| There are quite many browser-supported protocols which are
| not http or https, which can be used also for malicious
| purposes.
|
| HTTPS is probably the only protocol which is guaranteed to
| show content from the claimed source.
| galleywest200 wrote:
| Not FTPS or SFTP?
| nicce wrote:
| Funnily these protocols are not supported by the Chromium
| or Firefox anymore.
| BenjiWiebe wrote:
| 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?
| londons_explore wrote:
| I would be very dubious of applying to a security position
| with any company where the link started http://...
| jenscow wrote:
| Why? They obviously need new expertise.
|
| Bricklayers don't avoid un-built houses.
| cmeacham98 wrote:
| Sure, if you're planning on applying to a powerful enough
| position that you'd be able to effect significant change.
|
| But for most jobs, where you aren't going to be able to
| affect massive change, you'll want the security culture
| not to bad/nonexistent.
| radiator wrote:
| If it is a public job description why must it be https?
| Baseless criticism might tell more about yourself than
| about them.
| londons_explore wrote:
| 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...
| eru wrote:
| If you want to claim that you are compliant (perhaps it's a
| tick mark somewhere), then you need to follow the rules.
|
| Btw, if you want to start with "http://" just declare it to
| be not-a-web URI. Eg say it's a git URI.
| NoZebra120vClip wrote:
| Section 5.7 of the same RFC actually lays out the reasoning
| and security considerations for mandating https.
|
| I'm not sure where "web URI" is defined, but I am pretty
| sure that a Git URI uses "git://" and Git-via-http is still
| a "web URI" method.
| pncnmnp wrote:
| 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.
| archerx wrote:
| Sorry but I don't want anyone fingering my server thank you
| very much.
| ChoGGi wrote:
| It's your servers fault for dressing in vulnerable
| clothing.
| serial_dev wrote:
| 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.
| midasuni wrote:
| Don't set a cookie and you don't need a cookie banner.
|
| Websites choose to display that banner, they don't have to.
| b33j0r wrote:
| 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)
| chrismorgan wrote:
| 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:
|
| https://datatracker.ietf.org/doc/html/rfc9116
|
| https://www.rfc-editor.org/rfc/rfc9116.html
| eru wrote:
| 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.
| benatkin wrote:
| 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.
| oefrha wrote:
| 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.
| viraptor wrote:
| 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.
| andersa wrote:
| What if they're trying to report a critical issue with your
| payment processing?
| hypeatei wrote:
| Too bad, it's not my financial info at risk anyways. ;)
| jagged-chisel wrote:
| Straight to the bin.
|
| Obviously. >.<
| viraptor wrote:
| 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.
| dns_snek wrote:
| > 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.
| viraptor wrote:
| 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.
| [deleted]
| [deleted]
| dools wrote:
| 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.
| burnished wrote:
| Why do SPF and DKIM go to the bin? I have just recently begun
| my initiation to the mysteries of email. Is it nonsense
| reports or something?
| warp wrote:
| 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).
| kirab wrote:
| 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.
| jabroni_salad wrote:
| 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.
| kirab wrote:
| People can still malicously send emails in your name,
| even without an mx record.
|
| Don't trust my word for this, have a look at CloudFlares
| article about this:
|
| "How to protect domains that do not send email"
|
| https://www.cloudflare.com/learning/dns/dns-
| records/protect-...
| jabroni_salad wrote:
| "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.
| megous wrote:
| Having SPF/DKIM in DNS records doesn't prevent that.
| LeonM wrote:
| This is exactly what SPF and DKIM are designed to do.
| DMARC enforces this.
|
| Obviously, this is opportunistic security, the receiver
| must support all this, but >99% does.
| megous wrote:
| Yes, but the public testers are not testing the receive
| side, but the sending side.
| ryan-c wrote:
| There are, in fact, non-frivolous DKIM issues, such as DKIM
| selectors for which the private key is available or can be
| cracked.
|
| Historically, 512 bit RSA was somewhat common, and old
| selectors don't always get removed.
| a2800276 wrote:
| "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."
|
| Somewhat ironically:
|
| https://www.digitaltrustcenter.nl/security.txt
|
| The website of the Digital Trust Center returns 404
| Mattasher wrote:
| https://www.digid.nl/security.txt
|
| redirects to:
|
| https://www.ncsc.nl/.well-known/security.txt
| -----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/zNVUvpyqJfS8pNzG0p
| A B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz
| 192gWJvhxq8 mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0
| VZHfzF05Hr6NOoWvS6SRX KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93
| AmYkP/sBWP4It3NpbiNuazc5iynhhih +ZlfzsFV6agF4MZR0IQZ6X4
| jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC 2rro6N9FXSyxH
| z9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ wAl
| s9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq
| lNVMWzOncidAWM0nXcuYTjZagRAagthF =yC4A -----END
| PGP SIGNATURE----- Version: Encryption Desktop 10.4.2
| (Build 1298) Charset: utf-8
|
| wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6
| v YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG
| 0pA B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJ
| vhxq8 mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOo
| WvS6SRX KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuaz
| c5iynhhih +ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDj
| Deiinid0HOC 2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0r
| TcjUucaVikFJQ wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOj
| NgbmeQOlH4jnYWq lNVMWzOncidAWM0nXcuYTjZagRAagthF =yC4A -----END
| PGP SIGNATURE-----
| smcleod wrote:
| Wouldn't it be beveiliging.txt?
| pluijzer wrote:
| How about beveiliging.tkst?
| teekert wrote:
| Us Dutchies, in contrast to the French, don't come up with
| new words. Our language is Englishifying more and more.
| vanderZwan wrote:
| 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
| "helicoptere", until the Canadians liberated us). It's
| probably not surprising that WW2 made German less popular,
| and the Anglosphere more popular afterwards.
| sebstefan wrote:
| Cesses de televerser des billevesees sur hackernews,
| Hollandais
|
| Notre langage est parfait
| teekert wrote:
| Excuse moi, je suis een baquette.
| WJW wrote:
| > sur hackernews
|
| "nouvelles de pirates", surement? :)
| [deleted]
| mathstuf wrote:
| 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 "ARRET" 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.
| rerx wrote:
| 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_Conventi
| on_on_Road_Sign... That makes it a bit easier to drive
| safely across countries without reading all local
| languages.
|
| Edit: Huh, apparently "stop" or the equivalent in the
| local language are allowed by the treaty. Didn't know
| that. https://en.wikipedia.org/wiki/Stop_sign
| justsomehnguy wrote:
| > apparently "stop" or the equivalent in the local
| language are allowed by the tr
|
| Yes, but this is the only octagonal sign in the treaty, I
| suppose specifically so it's meaning could be inhered
| without knowing local language
| NVQXE23I wrote:
| 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.
|
| So, the URL becomes: https://www.digitaltrustcenter.nl/.well-
| known/security.txt
|
| This returns a 200 (via 302).
| moffkalast wrote:
| Ironically, that information is apparently not well known.
| jl6 wrote:
| I do get why they standardized it that way, but boy is it
| ugly.
| archerx wrote:
| 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.
| onlypositive wrote:
| I wasn't going to add one but I might actually put one in
| my root just out of spite.
|
| Devs need to stop demanding other devs jump through
| pointless hoops.
| withinboredom wrote:
| On linux, there is a ~/.config directory, yet devs who
| think they know everything still pointlessly litter my
| home directory...
|
| Don't litter your web root either ;)
| _nalply wrote:
| 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)
| xp84 wrote:
| 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.
| throwawaaarrgh wrote:
| 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.
| yard2010 wrote:
| How about a fax number?
| omgwtfusb wrote:
| welcome to Germany
| red-iron-pine wrote:
| or Japan
| yread wrote:
| https://mijn.overheid.nl/security.txt
|
| 404
|
| but this one does exist https://www.ncsc.nl/.well-
| known/security.txt
| wombarly wrote:
| Your first link is incorrect, it should be:
|
| https://mijn.overheid.nl/.well-known/security.txt
|
| which redirects to the second one.
| jwilk wrote:
| security.txt discussed on HN:
|
| 2017: https://news.ycombinator.com/item?id=15416198 (145
| comments)
|
| 2019: https://news.ycombinator.com/item?id=19151213 (55 comments)
|
| 2021: https://news.ycombinator.com/item?id=26455493 (167
| comments)
| milliams wrote:
| I've just checked the UK's GDS advice and they have it as a
| "should": https://gds-way.cloudapps.digital/manuals/security-
| overview-...
|
| They have more information at https://gds-
| way.cloudapps.digital/standards/vulnerability-di... where they
| strengthen the advice by saving: As per the
| current policy, we only accept reports from services that have a
| security.txt file pointing to the security policy.
| InCityDreams wrote:
| >I've just checked the UK's GDS advice and they have it as a
| "should":
|
| Without forgetting that a UK 'should', is considerably
| different to a US 'should'.
|
| .nl? - I'll let you guys decide.
| PrimeMcFly wrote:
| > As per the current policy, we only accept reports from
| services that have a security.txt file pointing to the security
| policy.
|
| So if their security.txt doesn't point to a service someone
| finds an issue with they won't respond?
| iLoveOncall wrote:
| Or they will respond by slamming down your door at 6AM :D
|
| I take it as a way to say "don't even think of touching the
| services that don't have the security.txt file".
| londons_explore wrote:
| I think it means "our team isn't responsible for services
| without a security.txt, so don't contact us about it"
| plugin-baby wrote:
| Should the title be "security.txt" instead of "Security.txt"?
| junon wrote:
| Might be HN's auto-capitalization behavior when submitting.
| xdfil wrote:
| [dead]
| hoofhearted wrote:
| 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?
|
| https://github.com/elegantframework/elegant-cli
| hoofhearted wrote:
| I got a few upvotes so far, but no comments! Lol
|
| I may put out a few feelers, and put this topic up for a RFC
| and discussion on GitHub.
|
| It seems like an interesting new little web thing, and is super
| easy to implement.
|
| I just share the same concerns as others have mentioned with
| bots and spammers misusing this file.
| cuttysnark wrote:
| 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.
| hoofhearted wrote:
| 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.
|
| I appreciate your feedback!
|
| I have opened an RFC and will be pushing this idea through
| the feature pipeline ASAP:
| https://github.com/orgs/elegantframework/discussions/55
___________________________________________________________________
(page generated 2023-06-01 23:02 UTC)