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

101–110 of 148 posts

Re: Security.txt

#101

Post by askvictor »

solatic wrote: post #98
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.

Good points, though those should be spelt out in the original document/site

Re: Security.txt

#102

Post by rtpg »

CiPHPerCoder wrote: post #100
rtpg wrote: post #99

Earlier quoted context omitted.

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

Yeah that post makes a lot of sense. It seems like this would establish a norm of generally trying to coordinate with a vendor in many circumstances (if a web service is vulnerable hard for users to fix it themselves after all).

Might of misread what "norm" meant here

Re: Security.txt

#103

Post by graystevens »

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…

Agreed regarding trying to get the information in front of the right people, or even just into the company. Recently been trying to contact 20-30+ companies regarding public exposure of private data, and I’ve had a real spectrum of results...

Some had a bug bounty/disclosure program, and fixed it within minutes. Some had CERTs... who never acknowledged the email. Some didn’t have any public contact methods, so had to hunt for them via google. Some acknowledged the issue, removed the private data but didn’t fix the actual ‘hole’...

On the whole, I spent more time trying to find contacts for websites, than actually finding the issue(s).

Re: Security.txt

#104

Post by im3w1l »

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…

> You can state your preference that I coordinate with you... but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude.

I think you are in the minority on this. If the hacker community go too far in this direction don't be surprised if there are calls to reign it in with legislation.

Re: Security.txt

#105

Post by hannob »

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.

Re: Security.txt

#106

Post by lifeisstillgood »

libeclipse wrote: post #20
Top19 wrote: post #12

Earlier quoted context omitted.

Can you expand more on this? What do you mean by “much deeper than html”?

He means if you have a domain you can pretty much serve whatever you want off of it.

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)

Re: Security.txt

#107

Post by Canada »

im3w1l wrote: post #104
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…

> You can state your preference that I coordinate with you... but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude. I think you are in the minority on this. If the hacker community go too far in this direction don't be surprised if there are calls to reign it in with legislation.

If I find a bug on my own I can do as I please with it. I have no obligation to inform the vendor. I can write an exploit and publish it, share it with my friends, or sell knowledge of it to whomever I please. The vendor has zero right to my work or to dictate what I do with it.

There are few things more frustrating than dealing with a vendor that doesn't understand this.

On the other hand, if I find something while being paid to look then I must tell only the client and hope that they are responsible enough to disclose it instead of silently patching.

I don't these are minority views.

Re: Security.txt

#108

Post by xorcist »

gerdesj wrote: post #72
Spivak wrote: post #63

Earlier quoted context omitted.

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.

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…

> they are really just TXT with an API

No, they're really not. An SRV record points to a hostname, not an arbitrary string. You can do lookups in one RTT, not two.

Re: Security.txt

#109

Post by TeMPOraL »

Canada wrote: post #107
im3w1l wrote: post #104

Earlier quoted context omitted.

> You can state your preference that I coordinate with you... but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude. I think you are in the minority on this. If the hacker community go too far in this direction don't be surprised if there are calls to reign it in with legislation.

If I find a bug on my own I can do as I please with it. I have no obligation to inform the vendor. I can write an exploit and publish it, share it with my friends, or sell knowledge of it to whomever I please. The vendor has zero right to my work or to dictate what I do with it. There are few things more frustrating than dealing with a vendor that doesn't understand this. On the other hand, if I find something while…

> There are few things more frustrating than dealing with a vendor that doesn't understand this.

I think they do understand this very well; they just want to brainwash people into thinking it's a civic duty to do what they say. It's not. Ethical security researchers' responsibility is to the users, not to the vendors.

Re: Security.txt

#110

Post by zaroth »

Canada wrote: post #107
im3w1l wrote: post #104

Earlier quoted context omitted.

> You can state your preference that I coordinate with you... but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude. I think you are in the minority on this. If the hacker community go too far in this direction don't be surprised if there are calls to reign it in with legislation.

If I find a bug on my own I can do as I please with it. I have no obligation to inform the vendor. I can write an exploit and publish it, share it with my friends, or sell knowledge of it to whomever I please. The vendor has zero right to my work or to dictate what I do with it. There are few things more frustrating than dealing with a vendor that doesn't understand this. On the other hand, if I find something while…

The line is crossed if you attempt to market and sell it for illicit use, or a prosecutor thinks they can demonstrate that you did effectively that. See: recent case about the guy writing the remote system control software then became a popular hacking tool / RaT.
Post reply on HN