The greater issue is that browsers are allowing code executing from the public Internet scope (scope meaning security domain) network access to the localhost scope or the Intranet scope (RFC1918 addresses.) If anything, this should require very explicit permission granting from the user. I’d prefer it be something more like an undocumented toggle accessible solely to developer types.
The company may be interested in whether they want to grant access to the user to access to their systems. Does the user shoulder any responsibility?
How does it work in practice? It seems in Chrome these errors cannot be caught try-catch blocks. try { var socket = new WebSocket('ws://localhost:808'); } catch (ex) { console.log(ex) // control does not reach here }
It probably fires as an async error, I'd expect this would log it (if inserted at the end of the try block):
> I hack on Mastodon and it uses WSS for streams and they're very helpful. I'm not familiar with Mastodon or WSS. Can you describe how using WSS make the end user's experience better? What would be different if web sockets weren't used?
Mastodon is a federated/distributed social networking server that communicates with other servers via a protocol called ActivityPub. The interface feels sorta like Twitter, but it doesn't have to be. There are other FOSS ActiviyPub servers such as Pleroma (written in Elixir), Pixelfed (Instagram type interface) and PeerTube (distributed video). ActivityPub is a protocol (like e-mail/SMTP) for subscribing and replying…
> to the localhost scope or the Intranet scope That's too little. All access from a different origin should be blocked by default, not only to local nets.
I stand corrected. I think yours is the correct approach. How shall origin be defined? I can envision the likes of Microsoft which have many, many second-level domains making calls between them. We can’t allow the site itself to grant access. How would this be managed, other than “please stop and think what a domain name is supposed to be before spraying your product across twelve of them?”
We already have a notion of origin that is used for most of the browser security policies (exact match of domain, protocol, port). Websockets allow servers to enforce this policy by sending an Origin header, but unfortunately observing the error messages/timing still allows you to determine if the port is open at the transport layer even if you can’t establish a connection. Since websockets routinely need to connect to different origins (they can’t be routed exactly like normal requests, though many CDNs/reverse proxies can handle both), browsers would need to remove the information leak themselves by normalizing error messages and timing across failures.
CORS is set by the target, so localhost CORS policy is directly in the hands of the user. intranet CORS policy is set by whoever operates that intranet service
You’re right; a bit of a brain fail there for me. Still, doesn’t mitigate attacks against non-HTTP speakers.
It does in the sense that you won’t be able to control the websockets payload, so the target server generally won’t respond. The problem here is that the information leak is happening prior to any data being sent over TCP, so the fact that the server will drop the connection as invalid doesn’t help.
> to the localhost scope or the Intranet scope That's too little. All access from a different origin should be blocked by default, not only to local nets.
That's what CORS is for, but it appears that there is no CORS for WebSockets.
This is because websockets were created after the same origin policy, so they have always sent the origin header that allows the server to filter connections. CORS was only needed because the browsers were adding the same origin policy to HTTP requests that had historically never had it, so they needed some set of rules (and overrides for them) that didn’t break existing websites.
How does it work in practice? It seems in Chrome these errors cannot be caught try-catch blocks. try { var socket = new WebSocket('ws://localhost:808'); } catch (ex) { console.log(ex) // control does not reach here }
It probably fires as an async error, I'd expect this would log it (if inserted at the end of the try block): socket.onerror = (...args) => console.log('async error', ...args)
socket.onerror event happens for both cases. But there does not seem to be any difference between the error object that is passed to the these handlers.
Lots of chat in the comments about how this is all websockets' fault, but don't forget you can portscan localhost with pure JS as well. https://portswigger.net/research/exposing-intranets-with-rel...