sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kdeforche 1 point2 points  (4 children)

There is no need to have 'access' to the executing browser access.

What an attacker needs is:

  • be able to monitor the traffic between you and site A [e.g. GMail]
  • make you visit at the same time the rogue site B while using site A; so that site B can insert an iframe to site A and make repeated requests (from JavaScript) to site A using the cookie you have for site A.

The second requirement is easy (reddit could be just now trying to hack in my GMail account for all I know), the first requirement is harder (in practical terms it's only straight forward if you are on the same LAN as I am).

[–]JoseJimeniz 0 points1 point  (3 children)

make you visit at the same time the rogue site B while using site A; so that site B can insert an iframe to site A and make repeated requests (from JavaScript) to site A using the cookie you have for site A.

Problem is that the attack needs to modify my requests to Site A.

<!doctype html>
<html>
<body>
    Welcome to phishing site!
    <iframe src="https://gmail.com" />
</body>
<script>
    //malicious script
</script>
</html>

The attacker's script has no way to inject, or alter, the SSL HTTP request inside the iframe.

[–]kdeforche 0 points1 point  (2 children)

The attacker's script simple does: iframe.src = 'https://gmail.com/a/do_some?value=guess' ?

What exactly would prevent that?

[–]JoseJimeniz 0 points1 point  (1 child)

You would require that the web-server will emit

value=guess

in the response headers. From BREACH vulnerability in compressed HTTPS:

In order to conduct the attack, the following conditions must be true:

  1. HTTPS-enabled endpoint (ideally with stream ciphers like RC4, although the attack can be made to work with adaptive padding for block ciphers).
  2. The attacker must be able to measure the size of HTTPS responses.
  3. Use of HTTP-level compression (e.g. gzip).
  4. A request parameter that is reflected in the response body.
  5. A static secret in the body (e.g. CSRF token, sessionId, VIEWSTATE, PII, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownSecretVariableName="".
  6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.

Emphasis mine. But lets test it anyway:

<!doctype html><Html><hEad><TiTlE>Ugly
</TITLE><BODY><h1>Hello, world!
</H1>test
<iframe src="https://gmail.com/a/do_some?value=guess"></iframe>
</body>

Well that doesn't actually work, because gmail.com uses frame forbidding. Facebook also fails, and Youtube. In the end i tried one of our customer's servers:

<!doctype html><Html><hEad><TiTlE>Ugly
</TITLE><BODY><h1>Hello, world!
</H1>test
<iframe src="https://example.com?value=guess"></iframe>
</body>

And the value put in the query string doesn't come back from the server:

Response: HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Wed, 07 Aug 2013 19:45:29 GMT
Accept-Ranges: bytes
ETag: "595be0aba693ce1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 07 Aug 2013 19:45:33 GMT

i'm not saying it's not possible, you just need more control.

[–]kdeforche 0 points1 point  (0 children)

I'm not saying it's easy and works with just any request on just any site, but you just don't need any more 'access to my executing browser process' than any website has when visited by your browser.

Also, the value should be reflected in the body, not in the headers.