3 ms·
This is such an obvious consequence of web sockets that I wonder how anyone could have entertained the idea long enough to sober up and write the code. This is
by gnu8 6y ago
This is such an obvious consequence of web sockets that I wonder how anyone could have entertained the idea long enough to sober up and write the code. This is worse than letting a web page script have access to the clipboard, record mouse movements, and similar information leaks, because instead of just stealing information, now a web page can actively compromise any host on your network.
- crankylinuxuser 6y agoYep. Just waiting for this "feature" to be added to metasploit.
- wrkronmiller 6y agoI agree this is quite disturbing. It does not, however, sound like an attacker can establish arbitrary TCP connections (at least using the technique from the article). Instead, the attacker can determine if something is listening on a port because it will take a different amount of time to negotiate/drop a connection to a port when there is a listener than when there is not a listener. In other words, this sounds like a variant of a timing attack. As such, presumably, this particular avenue of attack can be mitigated by the browser vendor inserting a delay s.t. no information can be gleaned from how long it takes to negotiate/drop a websocket connection. EDIT: I also wonder if it would be possible to do a similar port scan using the timing of XHR requests to localhost (e.g. http://localhost:[port] http://localhost:[port]).
- throwphoton 6y ago> It does not, however, sound like an attacker can establish arbitrary TCP connections Maybe not, but what if the ports you have open actually are HTTP servers for development purposes? In that case wouldn't a website be able to crawl your unreleased work, and/or mess with what you're doing, with requests seemingly "out of nowhere"?