Security.txt
111–120 of 148 posts
Re: Security.txt
#112Good 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…
Hmm; I wonder, maybe in such case contacting some kind of national office which has the power to fine companies for breaching personal data protection laws could be an answer?
Re: Security.txt
#113Good 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…
Also, a lot of companies/orgs deny vulnerabilities exist or even “shoot the messenger.” Reporting is often an inconsistent, chaotic gamble, which pushes more people to either not report the issue, give up or go black hat to monetize their findings.
Re: Security.txt
#114Earlier quoted context omitted.
The more you use a Google feature as a crutch, the less the web is semantic. Also, Google has increasingly made it difficult to automate searches, so the effort required to notify multiple websites increases quickly.
> Also, Google has increasingly made it difficult to automate searches That's an understatement. Doing something as simple as inurl:"humans.txt" ...and consuming the first three pages showed me CAPTCHA. It was done via a browser, manually. Not all links were clicked.
Yep, I run across this often. Kind of funny that using a bit more advanced functionality instantly makes you suspicious.
Re: Security.txt
#115I smell an opportunity for spam bots.
Re: Security.txt
#116Good 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 disclosu…
Yup. They often claim you’re “malicious” to cover their incompetent butts. This is why reporting should be:
- end-to-end encrypted with a brand new, limited-time GPG key
- use a disposable email service
- make up an alias
- send from public WiFi at a coffeeshop some distance away that doesn’t have corporate CCTV
- Don’t bother with Tor or a VPN because it advertises “suspicious behavior” across network hops that maybe/are monitored/logged
If you volunteer information about your identity, it can be easily misused to attack you in a myriad of legal, professional, social media and other dirty-tricks ways.
Re: Security.txt
#117Here's my interview with Ed on the IETF proposal: https://www.bleepingcomputer.com/news/security/security-txt-...
Re: Security.txt
#118I think humans.txt ( http://humanstxt.org/ ) fits more, and already exists.
I've never heard of this. I wonder how many websites implement this. I tried a bunch of sites, but the only one I could find that had a humans.txt file was google: Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us…
I found this as part of a user agent in logs for my webserver: https://disqus.com/humans.txt
And going over my logs for the past year, I only found 6 requests for 'humans.txt' on my server.
Re: Security.txt
#119Earlier quoted context omitted.
abuse@: yes. postmaster@: no. If people have trouble contacting a business by email, they don't try to use email to fix the problem. They very sensibly go to the web site and try by phone or Twitter or some other medium that isn't the one that isn't working.
postmaster@ exists for many, many more reasons than non-deliverability. Again, multiple RFCs dictate its existence and management. Advice to the contrary demands a better rationale than you're providing, and is ill-advised. If you operate SMTP and I can't get through to you on postmaster@ ("yo, back off your retries," for example), I'm probably going to blacklist you. I'm not unique in the slightest. The decentralize…
Deliverability problems may be caused by misconfigured spam filters. Over-aggressive retries won't be.
So I see no justification there for paying staff to manually filter postmaster@ spam.
Re: Security.txt
#120Earlier 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…
> If I find a bug on my own I can do as I please with it.
only if your access to the vendor's systems wasn't precluded with an eula that you agreed to beforehand. I don't see company be stupid enough to not put in broad legal terms in the eula to prohibit this sort of penetration.
But if you weren't given permission first (which may involve said eula) then that must mean you're accessing without permission - which is illegal.