Stealing secrets from developers using WebSockets

&quot;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.&quot;<p>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.

This is why you don&#x27;t let @wongmjane inject code into websites. Imagine what features she&#x27;d learn about with tracebacks from developer machines! &#x2F;s<p>In seriousness, this is all because websockets aren&#x27;t bound by CORS, for good reason. <a href="https:&#x2F;&#x2F;blog.securityevaluators.com&#x2F;websockets-not-bound-by-cors-does-this-mean-2e7819374acc" rel="nofollow">https:&#x2F;&#x2F;blog.securityevaluators.com&#x2F;websockets-not-bound-by-...</a><p>There&#x27;s a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if they first receive a shared secret that&#x27;s loaded into the initial dev bundle, which itself would never be transmitted over a websocket and could be set via CORS to not be accessible to non-whitelisted origins. It&#x27;s a dead-simple protocol with no ongoing performance impacts. But understandable it hasn&#x27;t been implemented yet.

Oh well. I ended up adding these rules to uBlock Origin, suggestions for improvement welcome:<p><pre><code> ||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,third-party ||172.22.*^$important,third-party ||172.23.*^$important,third-party ||172.24.*^$important,third-party ||172.25.*^$important,third-party ||172.26.*^$important,third-party ||172.27.*^$important,third-party ||172.28.*^$important,third-party ||172.29.*^$important,third-party ||172.30.*^$important,third-party ||172.31.*^$important,third-party</code></pre>

Heads up to anyone who doesn&#x27;t already know, uMatrix[0] can be set up to block websockets by default from 3rd-party and&#x2F;or first-party domains. In the UI, websockets are grouped under the &quot;xhr&quot; column[1].<p>I&#x27;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&#x27;t take long to get used to. And honestly, a relatively large portion of the web works with only 1st party Javascript, and a surprising chunk of the web still works just fine with no Javascript at all.<p>This is also why I advise advanced users to run Firefox. uMatrix isn&#x27;t available for Safari, and it&#x27;s looking extremely likely that it&#x27;ll be at least underpowered in Chrome once Manifest v3 comes out. Or I guess run Brave or Vivaldi or whatever. Dang kids running around with their hipster browsers, I can&#x27;t keep track of them all.<p>The point is, even though I&#x27;m extremely bullish on the web as a secure application platform, part of the reason I&#x27;m bullish is because the web makes it relatively easy to take simple security measures like disabling scripts by default. You should absolutely take advantage of that, you should absolutely be disabling at least some Javascript features when you browse.<p>You can even globally turn off fingerprinting vectors like WebGL[2]&#x2F;Canvas[3] in Firefox, and just swap to a different profile whenever you want to visit the rare game&#x2F;app that requires them. Although with more and more people trying to embed their own DOM models in Canvas, maybe that&#x27;ll be harder in the future.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;gorhill&#x2F;uMatrix" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gorhill&#x2F;uMatrix</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;gorhill&#x2F;uMatrix&#x2F;wiki&#x2F;The-popup-panel#the-type-cells" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gorhill&#x2F;uMatrix&#x2F;wiki&#x2F;The-popup-panel#the-...</a><p>[2]: about:config -&gt; `webgl.disabled` -&gt; true<p>[3]: <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=967895" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=967895</a>

Given the news this has made, I sure hope browser vendors don&#x27;t overreact with blocking this too hard:<p>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.<p>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.<p>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)

I too like to hardcode my AWS secret keys in my frontend application

Why the actual fuck will a browser allow traffic to localhost from anywhere else?

Node debug mode runs a websocket, but the address is something like ws:&#x2F;&#x2F;0.0.0.0:9229&#x2F;1cda98c5-9ae8-4f9a-805a-f36d0a8cdbe8 - without the correct guid at the end, you can&#x27;t open the websocket and communicate. You can only detect the port being open by timing.

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

Is anybody keeping a list of potential security threats so browser vendors can check them off and the community can verify that they are correctly dealt with?

I just tested an approach to deny access to WebSockets in the browser. This only applies if the JavaScript and the page comes from a location you both control and your goal is to limit access from third party scripts and you don&#x27;t have access to the page&#x27;s server to add a Content Security Policy (CSP) rule restricting web socket addresses&#x2F;ports to specified rules.<p>TypeScript code:<p><pre><code> const sock:WebSocketLocal = (function local_socket():WebSocketLocal { &#x2F;&#x2F; A minor security circumvention. const socket:WebSocketLocal = &lt;WebSocketLocal&gt;WebSocket; WebSocket = null; return socket; }()); </code></pre> TypeScript definitions (index.d.ts):<p><pre><code> interface WebSocketLocal extends WebSocket { new (address:string): WebSocket; } </code></pre> If the &#x27;sock&#x27; variable is not globally scoped it cannot be globally accessed. This means third party scripts must know the name of the variable and be able to access the scope where the variable is declared, because the global variable name &quot;WebSockets&quot; is reassigned to null and any attempts to access it will break those third party scripts.

This websockets thing is getting more interesting very fast. I wonder how long it&#x27;ll be before someone finds something truly scary? This is the 3rd post this week, and each one has found a little bit more. Nothing that seems panic worthy yet. From this one:<p>&quot;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.&quot;

I wonder if this could be used to grab more sensitive data from apps that support browser extensions (e.g. from password managers that use websockets to communicate with browser extensions).

You&#x27;re likely not even safe from this if you are using Chrome OS. It does sandbox the localhost web server [1] [2], but it does not restrict access to it from the host.<p>[1]: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;pRlh8LX4kQI?t=954" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;pRlh8LX4kQI?t=954</a><p>[2]: <a href="https:&#x2F;&#x2F;chromium.googlesource.com&#x2F;chromiumos&#x2F;platform2&#x2F;+&#x2F;HEAD&#x2F;vm_tools#chunnel" rel="nofollow">https:&#x2F;&#x2F;chromium.googlesource.com&#x2F;chromiumos&#x2F;platform2&#x2F;+&#x2F;HEA...</a>

This is interesting, thanks for sharing. I wonder if a remediation for the moment would be for local websocket servers to check the Host header before sending the 101 switch protocol response. Also would a CORS &quot;Access-Control-Allow-Origin: localhost&quot; prevent the connections being established?

I get the following output when trying this with Create React App running:<p>{&quot;type&quot;:&quot;error&quot;,&quot;data&quot;:&quot;Invalid Host&#x2F;Origin header&quot;}<p>I don&#x27;t think I changed any significant settings in CRA, this is pretty close to the default. Not sure what exactly determines whether this works or not.

The server didn&#x27;t work for me, not sure if it&#x27;s a traffic issue or what.<p>I have at least 3 create-react-app and one next app running. I even ran a quick websocket server on port 3000 just to see but nada.

Interesting, history repeats. Didn&#x27;t browsers implement firewalls a while ago to prevent arbitrary requests? Remember doing things like CSRF attacks on SMTP, POP (any text based protocol basically) and stuff like that long ago, but Firefox added mitigations to prevent connections to certain ports - I guess that browser Firewall feature can be used as mitigation to prevent these attacks.

Forget port scanning for a sec. Couldn&#x27;t you just scan the whole local network for common vulnerabilities, like any old virus would?

&gt; browsers allow websockets from public origins to open websockets connections to localhost without many protections<p>Excuse me, but what in the world? XHR has all kinds of cross-site request protections that even make developing apps locally a pain. How come websockets don&#x27;t come with such protections?<p>Are there apps that take over this responsibility?

It strikes me that this is most likely to be used as part of an exfiltration mechanism for a malicious JS package or similar.

I&#x27;m assuming this can be mitigated by using SSL&#x2F;TLS. Have a read over at <a href="https:&#x2F;&#x2F;crossbar.io&#x2F;docs&#x2F;Secure-WebSocket-and-HTTPS&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crossbar.io&#x2F;docs&#x2F;Secure-WebSocket-and-HTTPS&#x2F;</a> - Not sure how you would do certificate pinning though.

Can&#x27;t you use CSRF to protect against this?<p><a href="https:&#x2F;&#x2F;dev.solita.fi&#x2F;2018&#x2F;11&#x2F;07&#x2F;securing-websocket-endpoints.html" rel="nofollow">https:&#x2F;&#x2F;dev.solita.fi&#x2F;2018&#x2F;11&#x2F;07&#x2F;securing-websocket-endpoint...</a>

If you use uBlock Origin, you can prevent any connections to localhost by default.

It&#x27;s worth noting that secrets rarely live in front-end code, specifically because it&#x27;s impossible to prevent people from extracting them.

Are there any extensions to block connections to localhost from code on other interfaces or origins?

After ~10 minutes I get: &quot;Connected to 0 servers&quot;<p>Ahh, feels so good

when I disable websocket with network.websocket.max-connections = 0, then whatsappweb doesn&#x27;t work, so perhaps someone can develop a related attack here?

Is webpack-dev-server planning on fixing this?

This is why you use VMs with their own network interfaces to do development in

Is the TL;DR here just &quot;webpack-dev server doesn&#x27;t verify Origin headers for hot reloading?&quot;<p>Is there a whole group of people that are just learning about Websockets for the first time?