Live data from Hacker News

Stealing secrets from developers using WebSockets

medium.com

61–70 of 146 posts

Re: Stealing secrets from developers using WebSockets

#61
post #46

This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-... There's a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if the…

That’s exactly the solution I was thinking of. No end-user visible changes required, just change websocket to require a secret on initial connection. An easy way of doing this might be to use the web socket URL path or a query variable. Note that we’re relying on the websocket library code to do the right thing: https://tools.ietf.org/html/rfc6455#section-10.7

Example, and note: https://news.ycombinator.com/item?id=23261309

Re: Stealing secrets from developers using WebSockets

#62

Oh well. I ended up adding these rules to uBlock Origin, suggestions for improvement welcome: ||localhost^$important,third-party ||127.*^$important,third-party ||10.*^$important,third-party ||192.168.*^$important,third-party ||172.16.*^$important,third-party ||172.17.*^$important,third-party ||172.18.*^$important,third-party ||172.19.*^$important,third-party ||172.20.*^$important,third-party ||172.21.*^$important,thi…

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 there are no web socket endpoints that could be used to get the secret from the websocket when not passed in. (Like an index of paths.) The Node debugger is mentioned elsewhere here as an example and cautionary tale.

Paranoid folks could maybe trick their everyday browser into never connecting to localhost via various means, and there’s an argument that websockets deserve localhost third-party restrictions or prompts, but if I were an attacker, publishing a malicious package via the web is significantly easier and higher value. Also, websockets require JS so disabling JS is another workaround. But then the site could encourage you to enable it for other reasons...

Re: Stealing secrets from developers using WebSockets

#63
post #46

This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-... There's a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if the…

Websocket protocol defines Origin header to indicate which website tries to establish connection. Hot reload websocket server must check it and allow localhost connections only (at least by default).

Re: Stealing secrets from developers using WebSockets

#64

Oh well. I ended up adding these rules to uBlock Origin, suggestions for improvement welcome: ||localhost^$important,third-party ||127.*^$important,third-party ||10.*^$important,third-party ||192.168.*^$important,third-party ||172.16.*^$important,third-party ||172.17.*^$important,third-party ||172.18.*^$important,third-party ||172.19.*^$important,third-party ||172.20.*^$important,third-party ||172.21.*^$important,thi…

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…

https://en.wikipedia.org/wiki/DNS_rebinding

Re: Stealing secrets from developers using WebSockets

#65
post #48
post #13

And this is why you are supposed to check the origin and host headers before sending sensitive data to a web socket

Yeah, keep pimping these "mitigations" instead of a better security model that doesn't require everyone perfectly jumping through hoops. When you get fucked over by one of such security exploits it will be a great relief to know that it could have been prevented if only the software vendor did the right security voodoo dance (which gets more elaborate by the month). Edit: can't wait for the usual replies with "what i…

Its not really a mitigation if its the core security model. A mitigation is a work around. I guess technically a mitigation is anything that fixes the issue, but for example if someone had a password protected app that was hacked because it didnt check the password, i would not call actually checking the password a "mitigation"

Re: Stealing secrets from developers using WebSockets

#66
post #59

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.

If you have bound the server to localhost and not all interfaces, then no, people on your coffeeshop wifi cannot connect.

Re: Stealing secrets from developers using WebSockets

#67
post #64

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…

https://en.wikipedia.org/wiki/DNS_rebinding

I particularly like the “websites can reject unknown host header” solution as an extra form of protection against this. But we go back to the web socket server needing to inspect the URL and host headers it’s given. Also: https://news.ycombinator.com/item?id=23263983

Re: Stealing secrets from developers using WebSockets

#68

Oh well. I ended up adding these rules to uBlock Origin, suggestions for improvement welcome: ||localhost^$important,third-party ||127.*^$important,third-party ||10.*^$important,third-party ||192.168.*^$important,third-party ||172.16.*^$important,third-party ||172.17.*^$important,third-party ||172.18.*^$important,third-party ||172.19.*^$important,third-party ||172.20.*^$important,third-party ||172.21.*^$important,thi…

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 me that browsers just allow this, this should require a permission prompt.

Re: Stealing secrets from developers using WebSockets

#69
post #46

This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-... There's a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if the…

Websocket protocol defines Origin header to indicate which website tries to establish connection. Hot reload websocket server must check it and allow localhost connections only (at least by default).

It might not be localhost or a local IP if users use a different hostname, common for some environments, at which point it would have to be configurable. But yes, that could also work, if all browsers send Origin headers as expected.

Re: Stealing secrets from developers using WebSockets

#70
post #48
post #13

And this is why you are supposed to check the origin and host headers before sending sensitive data to a web socket

Yeah, keep pimping these "mitigations" instead of a better security model that doesn't require everyone perfectly jumping through hoops. When you get fucked over by one of such security exploits it will be a great relief to know that it could have been prevented if only the software vendor did the right security voodoo dance (which gets more elaborate by the month). Edit: can't wait for the usual replies with "what i…

> The obvious flaw in modern web security is that the domain isolation model does not make any sense today. It's an outdated hack. Software communication should be done thorough something resembling actor model where code running locally is thought of as completely separate entity from the web server. It shouldn't have anything to do with domains. Communication from any actor to any other actor should be subject to the same security model, regardless of where their code was loaded from. Escalating privileges between actors should be a universal and well-established process with known guarantees, not a bloody mess of ad-hoc conventions, headers and "best practices" that change with every browser, app and year.

How would that change anything? The flaw is the websocket was open to anyone (on the application layer. All security in the example was due to what ip addressess the websocket binded to on the network layer). If you replace the same origin policy with some other security policy, it wouldn't really make a difference, unless your web socket decided to use it, and in that case you might as well use the existing same origin policy.

If your real argument is that CORS/same origin policy/websocket security policy is inconsistently specified and has made some questionable specification decisions - sure i agree with you. But that has nothing to do with using origin as the security domain for websites

The fundamental flaw here is using the ip address and assumed sufficientness of only binding to 127.0.0.1 as a security measure without application level mitigation, not how browsers do network security

Edit: reflecting on this, i think i change my mind a bit. The fundamental problem isn't that the web security model is full of hacks, but that the websocket spec decided to ignore it and instead focus on the socket (tcp connection) model of secirity. If you open a socket all the server has to authenticate is the ip address. Anyone can open a socket to anywhere, any orher authentication has to be taken from higher level protocol. In websockets, its mostly the same. Anyone can open to anywhere, and webserver just has ip address and origin to authenticate. Anything else should be done in higher level protocol. The problem is people see websocket and assume WEBsocket not webSOCKET.

Post reply on HN