Stealing secrets from developers using WebSockets (opens in new tab)

I used to have some co-workers who would dump json docs containing sensitive information into these sites all the time, and despite showing them how to format stuff in VS Code.

http://www.hntoplinks.com/all

The same origin policy was originally introduced with AJAX at a time when the vast majority of traffic was to the same origin. It wasn't a common pattern to make complex requests to a different domain (barring GETs and FORM posts which were allowed).

Web development changed and it started to become more popular to make complex cross-domain requests, but the problem is they couldn't just throw out the SOP without introducing a massive security vulnerability to all existing sites. So instead CORS was introduced as an option to relax the SOP.

With websockets being completely different, it was an opportunity to "start over". They opted to embrace cross-domain communication and require developers implement security on top of it.

The `postMessage` API has done the same thing. Any window can `postMessage` to any other window -- it's fully up to the windows to validate the security of messages coming their way.

Some argue that it's a bad idea to make "allow by default" the new paradigm. Personally, it seems pretty clear to me that developers just don't understand CORS at all [0], and letting the developers handle this in their own logic, while being exceptionally clear about this in the documentation, is a far more developer friendly and simple (therefore more secure) approach.

[0]: https://fosterelli.co/developers-dont-understand-cors

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.

When I do not want the browser to access somedomain.com, I redirect somedomain.com to 127.0.0.1 in my hosts file

Compared to alternative platforms, security on the web is easy.

Also keep in mind the audience. If I was posting this on Facebook or Twitter, I might not make the same recommendations, but uMatrix is not too complicated for the average HN reader to use. It might be annoying and you might decide you don't want to have to turn it off or fiddle with it for some websites, but the learning curve is really not that steep if you have even a rudimentary knowledge about how websites work.

   evil-server
      (looks at data from client)
      (recognizes well known server app)
         (launches exploit!)

- you would probably only need a handful of ports

- it really only takes one person pasting that AWS key into their file to get pwned and I’m sure someone has those keys committed to GitHub right now.

- how many tabs do you have open of random tech blogs right now? Excluding HN, my guess is the average dev has at least one.

Not a super plausible attack, but over a long period of time with decent SEO, could probably deliver some interesting results.

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.

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.

However there are still so many different ways to defeat this (e.g. creating a web worker, creating a new window that handles the WebSocket and posting messages to it, etc.) that it's basically pointless to try.

Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures.

CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.

With Websockets something like this is effectively not possible, because WebSockets were designed with this in mind

- A browser will only start transmitting data over the ws once the handshake is done. So just making a request has very limited ways for an attacker to transmit user defined data (basically the Host header/Origin header and cookies... which will not really work as an attack vector for newline-delimited or binary protocols)

- The handshake itself works by the client sending a nonce to the server which the server then has to hash together with a special uuid. Only actual websocket servers know how to do this step correctly, and thus the browser will refuse to even open connections to servers which aren't actual websocket servers. So the attacker will not be able to send truly arbitrary data or read any responses.

- Even after the handshake, browser-to-server data is masked by XORing the data with browser-picked keys. The attacker therefore cannot control what the data will end up looking like when it is sent to the server. And unaware servers will certainly not try to reverse the XORing.

What you're left with regarding websockets are timing attacks to do some port and network scanning, and attacking actual websocket servers, which do not check the Origin or use some kind of token to verify incoming connections, analog to attack-able regular http endpoints that do not do auth and csrf tokens properly.

I'll readily admit tho, that a lot of developers forget about verifying incoming websocket connections. I have fucked this up myself in the past, and I have found such issues in other websites, including one problem that let me take over user accounts via an unsecured websocket if I was able to get such users to open an attack website (or ad).