Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security.txt

securitytxt.org

Post reply on HN
Print view View original

91–100 of 148 posts

Re: Security.txt

#91

Post by jlgaddis »

kuschku wrote: post #60
jsmthrowaway wrote: post #4

Earlier quoted context omitted.

> 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 origina…

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…

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.

Re: Security.txt

#92

Post by anonymousjunior »

disconnected wrote: post #70

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 s…

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

Here, now that I've shown you that, let me show you the MITM I've been running during the conference! So far I've collected NNN credential sets

Re: Security.txt

#93

Post by freedomben »

dsacco wrote: post #67

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…

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.

Re: Security.txt

#94

Post by freedomben »

manigandham wrote: post #80

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.

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.

Re: Security.txt

#95

Post by askvictor »

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)

Re: Security.txt

#96

Post by cyphar »

jlgaddis wrote: post #90
snakeanus wrote: post #49

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

What precludes you from including a comment with a link to the signed version of the file with ".asc" appended to the filename?

Nothing, but then it's an extension to a spec for a five-line plaintext file. Seems quite wasteful.

Re: Security.txt

#97

Post by cyphar »

unixhero wrote: post #57

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

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

Re: Security.txt

#98

Post by solatic »

askvictor wrote: post #95

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)

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.

Re: Security.txt

#99

Post by rtpg »

tptacek wrote: post #64

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 ad…

> 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

Is there really no norm to at least try and contact the affected service before publishing an exploit? Seems like basic courteousy, though I understand some people are not super receptive.

Re: Security.txt

#100

Post by CiPHPerCoder »

rtpg wrote: post #99
tptacek wrote: post #64

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 ad…

> 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 Is there really no norm to at least try and contact the affected service before publishing an exploit? Seems like basic courteousy, though I understand some people are not super receptive.

> Seems like basic courteousy

Read https://adamcaudill.com/2015/11/19/responsible-disclosure-is...

Post reply on HN