7 ms·
If I'm reading this correctly, the attack requires specially crafted JS to be slipped into the target browser. But aren't you already screwed if third parties c
by kijin 15y ago
If I'm reading this correctly, the attack requires specially crafted JS to be slipped into the target browser. But aren't you already screwed if third parties can slip arbitrary JS into your pages? It would be great if somebody could explain this in more realistic terms.
- willvarfar 15y agoIf I understand it correctly: Someone with access to any unencrypted HTTP stream - think ISP or wifi-sharer or (especially) government or cybercriminal - can slip in javascript that, in one browser window, gives the attacker the information needed to decrypt the secure streams in other browser windows. They do not need to find an exploit in your browser to jump from an insecure browser session to your secure sandbox beside it.
- redthrowaway 15y agoHow would they jump sandboxes? Wouldn't that require a browser-specific attack? For example, how would some injected code on HN jump over to my secure banking tab, in another chrome process?
- caf 15y agoPresumably the injected code creates specially crafted requests to the SSL site being attacked - it can't read the results of those requests, but that doesn't matter: its only purpose is to create some adaptively-chosen known plaintext for the sniffer.
- kijin 15y agoWouldn't that be blocked by cross-site AJAX restrictions? Or are we talking about injecting <img> and <script> tags into the document?
- caf 15y agoThe latter, or maybe iframes.
- scotth 15y agoNo, it wouldn't. With AJAX, the request always goes out, and is received and processed by the server if they choose to (most never check the request origin). Then, the server can decide whether or not to attach cross origin resource sharing headers to the response. If those headers exist, the response is exposed to JavaScript. If not, they are swallowed by the browser.
- redthrowaway 15y agoIn the case of Chrome (and other browsers are moving in the same direction), you should be able to check the pid of the instance you're dealing with. At least, I assume that's the case if they're offering native c++ support.
- chromic 15y agoOne of the main purposes of SSL is to prevent someone who may control the route from server to client from eavesdropping or injecting their own data, so the article assumes this situation: only the server and client are trusted. It's trivial to inject something into an unencrypted stream if you own the network, but they're saying they can slip in some arbitrary JS to an encrypted stream with about 10 minutes of work.
- jroll 15y agoOr decrypt that credit card number you just punched in.
- rorrr 15y agoIf somebody injects JS into your stream, you are most likely screwed, but it doesn't mean your cookies can be stolen. Cookies can be set to HttpOnly (and should be, if you're trying to operate a secure site).
- alecco 15y ago+Secure flag to block sending the cookies over plain HTTP.
- itsnotvalid 15y agoI am guessing that they are able to bypass this restriction.
- alecco 15y agoNo, the attack is against SSL and Man-in-the-Middle. They just make the browser send SSL requests with those cookies, and then guess the cookie (sent inside the SSL session).
- ajross 15y agoYou're in luck! I have a Chrome extension that prevents just that. Let me send you a copy you can install for yourself...
- deleted 15y ago[deleted]
- ams6110 15y agoPresumably running a plugin like noscript or disabling JS would mitigate this attack, then. I wonder if at some point we're going to have a backlash against JS apps, which are really just the fat clients of the 1990s in a new container, as attackers discover more and more exploitable weaknesses in client JavaScript implementations.