71–80 of 146 posts
"In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code." Wrap the exploit up in a blog post about Rust -- or an article about gut bacteria -- and submit it to Hackernews. Boom, a virtual feast of secrets.
Earlier quoted context omitted.
That won’t help if someone sets up public DNS to point to localhost or 127.0.0.1 though. Unless you check after DNS is resolved? It’s also possible someone might bind to an IPv6 address. Better to rely on fixes mentioned elsewhere for web socket servers running on the local machine, including inserting a secret key into web socket path or query param, ensuring the web socket validates the path or query, and ensuring…
Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network. What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall. It amazes…
https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/
the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks.
Other DNS Resolvers have similar settings.
Earlier quoted context omitted.
That won’t help if someone sets up public DNS to point to localhost or 127.0.0.1 though. Unless you check after DNS is resolved? It’s also possible someone might bind to an IPv6 address. Better to rely on fixes mentioned elsewhere for web socket servers running on the local machine, including inserting a secret key into web socket path or query param, ensuring the web socket validates the path or query, and ensuring…
Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network. What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall. It amazes…
Fact is, internet connected devices need to be secure, and NAT as a security tool has to be stopped, it’s just one really convenient security layer, but is relatively easy to work around, so it’s not inherently secure on its own...
I am also reminded of Internet Explorer Security Zones, where you could define different rules for your local network vs the public internet. And Home vs Work vs Public wifi connections on Windows. These days, though, most users aren’t going to configure their networks to this degree... safer routers are perhaps the only easy way to start, but folks hate getting lots of notifications, so it’s unclear how any general purpose solution would work beyond localhost.
Earlier quoted context omitted.
Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network. What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall. It amazes…
The best way to protect against DNS rebinding attacks is at the DNS server level on your local network. https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks. Other DNS Resolvers have similar settings.
Earlier quoted context omitted.
The best way to protect against DNS rebinding attacks is at the DNS server level on your local network. https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks. Other DNS Resolvers have similar settings.
The DNS resolver/server is still resolving 127.0.0.0/8 and ::1 with these settings.
Why the actual fuck will a browser allow traffic to localhost from anywhere else?
Because the web is supposed to be a web of multiple sites, built my multiple people, sharing a web of resources. Localhost is just another site. If you want to make it secure, make it secure. You realize that anybody on your coffeeshop wifi can also connect to your localhost server, don't you? Just because a server is running on your laptop doesn't mean it's not a server, running on the internet.
Also at least by convention, localhost is only accessible via the loopback interface. This allows it to be accessible even if there is no physical network to connect to, but also means that it is only accessible on the same physical/virtual computer that it is running.
To let other people in the coffee shop access your software you would need to connect to a public or private interface.
Earlier quoted context omitted.
Or use cookies, a token in the URL, or any of the existing CSRF mitigation strategies. This is not a new problem. Sensitive and destructive HTTP endpoints open to third-party origins is a bug with many existing solutions.
Implementing any of those require more work. The issue lies in the fact security is an afterthought for the Web.
I genuinely have a use-case for this. We have an internal company wide business app, that works in any browser. The usual create-read-update-delete stuff, reports, factory forms etc.
With websockets we solve communication with local devices on the shopfloor - some computers have serial-port attached thermal printers, others have usb attached notification lights. We have small python scripts that listen for commands with websockets on 127.0.0.1 and control the printers and lights.
That way we can control each users local devices from the web app - without configuring internal firewalls or installing special browser add-ons (an in-house browser add-on is a bigger security risk, than a websocket on 127.0.0.1)
Heads up to anyone who doesn't already know, uMatrix[0] can be set up to block websockets by default from 3rd-party and/or first-party domains. In the UI, websockets are grouped under the "xhr" column[1]. I'm a pretty big Javascript advocate, but I do recommend advanced users run uMatrix and consider disabling at least 3rd-party JS by default. uMatrix is a fantastic tool and it really doesn't take long to get used to…
I'd be happier if Firefox itself asked for permission before allowing web servers an websockets, but even this wouldn't be terribly helpful, as any authorized website (like agar.io) could then scan you.
"In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code." Wrap the exploit up in a blog post about Rust -- or an article about gut bacteria -- and submit it to Hackernews. Boom, a virtual feast of secrets.
How many people post on here about having hundreds of tabs open?