Stealing secrets from developers using WebSockets • Hacker News Board

Re: Stealing secrets from developers using WebSockets

#111

Post by perl4ever » Fri, May 22, 2020, 1:47 AM UTC

chrisfosterelli wrote: post #107

Ajedi32 wrote: post #103

Earlier quoted context omitted.

Developers not understanding CORS is simply all the more reason why it's good that CORS defaults to secure behavior whenever possible. The harder you make it for ignorant developers to shoot themselves (and their users) in the foot, the better. postMessage's API design has similar issues to WebSockets. MDN does a pretty good job of explaining the dangers (practically every other paragraph on the page for postMessage…

> Developers not understanding CORS is simply all the more reason why it's good that CORS defaults to secure behavior whenever possible. The harder you make it for ignorant developers to shoot themselves (and their users) in the foot, the better. Right, but not understanding something doesn't mean it is more difficult to shoot yourself in the foot -- in fact it's the opposite. The zoom vulnerability is an example of…

The last time I was getting annoyed with CORS preventing me from doing something, I wrote a VBA script that opened IE, loaded a random page from the site that was clashing, and injected javascript to do what I wanted.

...and I don't even have admin access to my own computer.

Re: Stealing secrets from developers using WebSockets

#112

Post by mehrdadn » Fri, May 22, 2020, 1:47 AM UTC

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

Re: Stealing secrets from developers using WebSockets

#113

Post by Ajedi32 » Fri, May 22, 2020, 1:53 AM UTC

chrisfosterelli wrote: post #107

Ajedi32 wrote: post #103

Earlier quoted context omitted.

Developers not understanding CORS is simply all the more reason why it's good that CORS defaults to secure behavior whenever possible. The harder you make it for ignorant developers to shoot themselves (and their users) in the foot, the better. postMessage's API design has similar issues to WebSockets. MDN does a pretty good job of explaining the dangers (practically every other paragraph on the page for postMessage…

> Developers not understanding CORS is simply all the more reason why it's good that CORS defaults to secure behavior whenever possible. The harder you make it for ignorant developers to shoot themselves (and their users) in the foot, the better. Right, but not understanding something doesn't mean it is more difficult to shoot yourself in the foot -- in fact it's the opposite. The zoom vulnerability is an example of…

I'm not trying to saying that CORS is harder to shoot yourself in the foot with because it's hard to understand. Rather, it's harder to shoot yourself in the foot with because not understanding it usually just means your site's pages aren't accessible to other origins at all. (That's one reason why so many developers seem to have so much trouble with it; rather than breaking their site's security and remaining completely unaware of it, they instead break their site's functionality instead and need to spend a bunch of "extra" time learning about CORS and the same origin policy before they can get it to work.)

In contrast, not understanding WebSockets usually means your WebSocket endpoints are completely insecure, with no indication that anything is wrong and no incentive to learn more because "it's already working".

Obviously secure-by-default is not completely foolproof. After all, defaults are, by definition, possible to change. But if developers are going to shoot themselves in the foot, I'd much rather them be forced to do so explicitly than have it happen to them implicitly without any action on their part.

Re: Stealing secrets from developers using WebSockets

#114

Post by earthboundkid » Fri, May 22, 2020, 1:55 AM UTC

bryanrasmussen wrote: post #58

codazoda wrote: post #25

Earlier quoted context omitted.

Exactly. I've got a blog with dozens of technical documents about JS and other topics. That would be an ideal place to harvest this type of information, from developers actively looking for a solution to a particular problem.

So the blog should have articles on how to set up and log into Service X using React! This explains why I see so many of these!

The average post quality on Proggit has gone down a lot in the last year. It would be funny if this were why.

Re: Stealing secrets from developers using WebSockets

#115

Post by EE84M3i » Fri, May 22, 2020, 2:09 AM UTC

Is the TL;DR here just "webpack-dev server doesn't verify Origin headers for hot reloading?"

Is there a whole group of people that are just learning about Websockets for the first time?

Re: Stealing secrets from developers using WebSockets

#116

Post by Avamander » Fri, May 22, 2020, 2:18 AM UTC

gruez wrote: post #18

edwintorok wrote: post #7

Earlier quoted context omitted.

DNS rebinding can be fixed at the DNS server level. OpenWRT has an option for it. But this websocket thing in browsers can't easily be turned off/mitigated AFAICT.

>DNS rebinding can be fixed at the DNS server level You can't always depend on that. eg. when you're on public/enterprise wifi that intercepts DNS requests.

This is why a local stub is a very good idea.

Re: Stealing secrets from developers using WebSockets

#117

Post by kerng » Fri, May 22, 2020, 2:34 AM UTC

Interesting, history repeats. Didn'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.

Re: Stealing secrets from developers using WebSockets

#118

Post by fendy3002 » Fri, May 22, 2020, 2:43 AM UTC

enkrs wrote: post #78

Given the news this has made, I sure hope browser vendors don't overreact with blocking this too hard: 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. With websockets we solve communication with local devices on the shopfloor - some computers have serial-port attached thermal printers…

CMIIW, this is doable without exploiting web socket. Make usual client traffic comes to room "A", then the rest (printer, etc) to room "B". Whatever message comes from "A" is rebroadcasted again to "B".

Unless I misunderstood your use case.

Also, obligatory xkcd 1172

Re: Stealing secrets from developers using WebSockets

#119

Post by odensc » Fri, May 22, 2020, 2:52 AM UTC

VWWHFSfQ wrote: post #110

austincheney wrote: post #108

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't have access to the page's server to add a Content Security Policy (CSP) rule restricting web socket addresses/ports to specified rules. TypeScript code: const sock:WebSocketLocal = (functio…

this is trivially defeated by a script that enumerates globals looking for something that extends or implements WebSocket

The `sock` variable wouldn't be global in this case though, so there's nothing to look for.

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.

Re: Stealing secrets from developers using WebSockets

#120

Post by austincheney » Fri, May 22, 2020, 2:56 AM UTC

VWWHFSfQ wrote: post #110

austincheney wrote: post #108

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't have access to the page's server to add a Content Security Policy (CSP) rule restricting web socket addresses/ports to specified rules. TypeScript code: const sock:WebSocketLocal = (functio…

this is trivially defeated by a script that enumerates globals looking for something that extends or implements WebSocket

Likewise that is solved for just as trivially by enumerating all globals and replacing any mention of WebSocket with your scoped variable. Of course though if all your code files are ECMA modules the only globals are those provided by the browser and third party scripts.