Comment

Comment by segfaultbuserr

It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #10419 - Can requests to 127.0.0.1 be used to fingerprint the browser [0] and has been fixed since then. Scanning localhost is a dangerous way to fingerprint the user if there are local open ports.

If you are not using Tor Browser and want to fix the security hole without disabling WebSocket completely, running the web browser in a separate network namespace is a workaround - you get a loopback interface which is independent from the main namespace, and you create a NAT interface within the network namespace to allow outgoing traffic. It's also a possibility for a website to probe other machines, such as the setting page on your router. For better protection, you should block all the local addresses defined by RFC1918 via netfilter/iptables as well.

For developers who needs less restrictive blocking for debugging, you can run multiple Firefox processes in different profiles (firefox -P --new-instance), each running in a different network namespace - to make it easy, you can code everything in a shell script and create desktop icons for them. I normally use an ad-blocked and 3rd-party-cookies-blocked profile for web browsing, but a naked Firefox profile for development.

[0] https://trac.torproject.org/projects/tor/ticket/10419

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton