Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stealing secrets from developers using WebSockets

medium.com

Post reply on HN
Print view View original

101–110 of 146 posts

Re: Stealing secrets from developers using WebSockets

#101

Post by jfkebwjsbx »

danShumway wrote: post #56

Heads up to anyone who doesn't already know, uMatrix[0] can be set up to block websockets by default from 3rd-party and/or first-party domains. In the UI, websockets are grouped under the "xhr" column[1]. I'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't take long to get used to…

> the web makes it relatively easy to take simple security measures like disabling scripts by default

The average user will never learn to configure and use software like uMatrix.

Re: Stealing secrets from developers using WebSockets

#102

Post by FridgeSeal »

pheme1 wrote: post #35
bitwize wrote: post #22

"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." 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.

Another idea: an online json editor

Are these not already phishing sites of some kind?

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.

Re: Stealing secrets from developers using WebSockets

#103

Post by Ajedi32 »

chrisfosterelli wrote: post #94
Ajedi32 wrote: post #85

Earlier quoted context omitted.

> In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-... As far as I can tell, that article only explains that WebSockets aren't bound by CORS. It doesn't provide a reason (good or otherwise) why WebSockets were designed that way. Personally, I consider that feature to be a design flaw. If WebSockets handshakes respected th…

It's a function of the natural evolution of things. 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…

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 contains a warning in bold text about properly validating the origin argument), but I think it would have been far better if the API forced devs to explicitly specify which origins they want to receive events from up front rather than relying on them to check the origin themselves after the message is received. I have little doubt there will be numerous vulnerabilities instigated by the current API design, despite MDN's warnings.

Re: Stealing secrets from developers using WebSockets

#105

Post by slimsag »

FridgeSeal wrote: post #102
pheme1 wrote: post #35

Earlier quoted context omitted.

Another idea: an online json editor

Are these not already phishing sites of some kind? 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.

Wouldn't be hard to adapt this to be literally one of your VS Code extensions.

https://github.com/microsoft/vscode-extension-samples/blob/m...

Re: Stealing secrets from developers using WebSockets

#106

Post by cjbprime »

m00dy wrote: post #44
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.

Or you can have this on firewall level.

No you can't -- the request from the browser is coming from inside the firewall, on an internal IP.

Re: Stealing secrets from developers using WebSockets

#107

Post by chrisfosterelli »

Ajedi32 wrote: post #103
chrisfosterelli wrote: post #94

Earlier quoted context omitted.

It's a function of the natural evolution of things. 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…

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 this, or every developer that just imports `cors()` middleware and runs it because "otherwise it gives some CORS error".

I'd rather an approach that is simple to understand, gives flexibility to the developers, and makes it crystal clear to them what their responsibilities are.

Re: Stealing secrets from developers using WebSockets

#108

Post by austincheney »

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 = (function local_socket():WebSocketLocal {
        // A minor security circumvention.
        const socket:WebSocketLocal = WebSocket;
        WebSocket = null;
        return socket;
    }());
TypeScript definitions (index.d.ts):

    interface WebSocketLocal extends WebSocket {
        new (address:string): WebSocket;
    }
If the 'sock' 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 "WebSockets" is reassigned to null and any attempts to access it will break those third party scripts.

Re: Stealing secrets from developers using WebSockets

#109

Post by [deleted] »

cygx wrote: post #53
ricardobeat wrote: post #49

Earlier quoted context omitted.

If the page does not have JS running, how would it check the time elapsed? i'm not seeing the vulnerability with noscript here.

Instead of merely printing 'ok', the page can request a resource from a server you control, eg via an element. You could probably even automate this via , along the lines of (untested):

[deleted]

Re: Stealing secrets from developers using WebSockets

#110

Post by VWWHFSfQ »

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
Post reply on HN