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

81–90 of 146 posts

Re: Stealing secrets from developers using WebSockets

#81

Post by afturner »

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…

Not sure of the best implementation, but couldn't it be behind a permissions dialog like the ones users have to accept for webcam access or notifications?

Re: Stealing secrets from developers using WebSockets

#83

Post by philsnow »

toupeira wrote: post #68
lstamour wrote: post #62

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…

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…

I agree about it being scary that the browser doesn't do more to prevent connections from from "localhost" to "not localhost".

https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only a couple weeks ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more.

I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both.

[0] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...

Re: Stealing secrets from developers using WebSockets

#85

Post by Ajedi32 »

btown wrote: 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…

> 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 the Same-Origin-Policy and CORS headers the same way every other HTTP request on the web does, none of these vulnerabilities with poorly implemented WebSockets servers would exist today, as they would be secure by default rather than "insecure unless the server properly validates the origin header on every handshake".

Probably too late to do anything about that anymore though. Changing WebSockets to respect the Same Origin Policy now would break a ton of websites.

Re: Stealing secrets from developers using WebSockets

#86

Post by zwetan »

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.

well that very same attack vector aka "visiting a web site" is what everyone had against Flash

how convenient to consider that "pretty slim" now

Re: Stealing secrets from developers using WebSockets

#87

Post by fenwick67 »

aarong11 wrote: post #82

I'm assuming this can be mitigated by using SSL/TLS. Have a read over at https://crossbar.io/docs/Secure-WebSocket-and-HTTPS/ - Not sure how you would do certificate pinning though.

I don't see what WSS would do to stop the local websockets dev server from serving a remote client. A remote client could just accept the connection without verifying the signature, yes?

Re: Stealing secrets from developers using WebSockets

#89

Post by [deleted] »

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

[deleted]

Re: Stealing secrets from developers using WebSockets

#90

Post by dpacmittal »

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…

You can achieve the same with http server as well. You'll just have to setup cors headers.
Post reply on HN