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

31–40 of 146 posts

Re: Stealing secrets from developers using WebSockets

#31

Post by ShaneMcGowan »

stestagg wrote: post #30
ShaneMcGowan wrote: post #20

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

Admittedly the example was a bit fake :) I /have/ put other secrets into frontend code before, strictly for small temporary projects where the cost of implementing secret management outweighs the size of the project. And obviously not in code that was anywhere close to being deployed outside my own box. Unfortunately the method outlined in the article allows access to environments that would otherwise be considered t…

I completely understand friend, have done the very same

Re: Stealing secrets from developers using WebSockets

#32

Post by inetknght »

edwintorok wrote: post #7
cjbprime wrote: post #6

Earlier quoted context omitted.

Super bad news about that: even if it didn't allow the `localhost` string, DNS rebinding allows the domain name of the site you visited to become 127.0.0.1. The answer to why browsers allow connections to 127.0.0.1 from external sites is probably something like "legacy reasons".

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.

Let me know how that works with DNS over HTTP

Re: Stealing secrets from developers using WebSockets

#35

Post by pheme1 »

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

Re: Stealing secrets from developers using WebSockets

#36

Post by parliament32 »

armchairchair wrote: post #28
qppo wrote: post #15

Earlier quoted context omitted.

This is one Show HN post away from an exploit in the wild

This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time c…

Exactly. This isn't websockets specific, you can portscan happily with pure JS. The issue is that browsers are allowing connections (from untrusted code) to private/loopback address space. This should really be behind a permission.

Re: Stealing secrets from developers using WebSockets

#37

Post by tasogare »

remram wrote: post #26
bawolff wrote: post #13

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

Or use cookies, a token in the URL, or any of the existing CSRF mitigation strategies. This is not a new problem. Sensitive and destructive HTTP endpoints open to third-party origins is a bug with many existing solutions.

Implementing any of those require more work. The issue lies in the fact security is an afterthought for the Web.

Re: Stealing secrets from developers using WebSockets

#38

Post by enahs-sf »

stestagg wrote: post #30
ShaneMcGowan wrote: post #20

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

Admittedly the example was a bit fake :) I /have/ put other secrets into frontend code before, strictly for small temporary projects where the cost of implementing secret management outweighs the size of the project. And obviously not in code that was anywhere close to being deployed outside my own box. Unfortunately the method outlined in the article allows access to environments that would otherwise be considered t…

Fake though the example may be, I wouldn’t underestimate its ability to stumble upon something useful if you could garner enough traffic.

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

Re: Stealing secrets from developers using WebSockets

#39

Post by armchairchair »

armchairchair wrote: post #28
qppo wrote: post #15

Earlier quoted context omitted.

This is one Show HN post away from an exploit in the wild

This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time c…

POC

https://jsfiddle.net/s9vzxctd/3/

Tested in Firefox ESR on Linux. Anything with about 3000ms time isn't a routable network address. Anything with a significantly longer or shorter time responds to a ping on my network.

Timings vary from browser to browser.

NoScript does block the requests before they ever leave your browser, reminding me why I use it.

Re: Stealing secrets from developers using WebSockets

#40

Post by ff7c11 »

winrid wrote: post #33

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

You can only make a websockets request. The javascript call will fail if either the port is closed, or the port is open but doesn't act like a websockets server. So you can tell if a port is open by the time it takes for the connection to fail. If it's actually a websockets server you hit, then you might get a useable bidirectional communication channel to it.
Post reply on HN