Hacker News Reader

Comment by oefrha | Hacker News Reader

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.

View on HN

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.

What if they're trying to report a critical issue with your payment processing?

Straight to the bin.

Obviously. >.<

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.

Too bad, it's not my financial info at risk anyways. ;)

> 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.

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.

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.

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.

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?

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.

Having SPF/DKIM in DNS records doesn't prevent that.

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.

Yes, but the public testers are not testing the receive side, but the sending side.

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.

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-...

"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.

No offense but I think you got the meaning of the record wrong:

https://community.cloudflare.com/t/keep-null-mx-in-addition-...

> 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".

Reply on news.ycombinator.com