RE: Cross-domain information leak with UI Security Directives

Hmm...

I think the case the security image that can be shown in an embedded context, (either because it lacks XFO or produces differential output from a stable, cross-user URI) is probably already insecure - the attacker could just use that kind of embedding to directly spoof the page.

There are also probably other side channels that would allow determining a user's logged-in state, and I don't know if that is by-itself a serious issue.

Maybe a more interesting attack is a site that offers a game where numbers appear in different parts of a play area and you're supposed to click on them, whack-a-mole style.  Behind the scenes, it's briefly showing a repositioned, framed view of a specific area of your bank account summary screen, then replacing it again with a guess with an input-protection rule.  If the user's click gets delivered intact, they guessed right, if the click has the unsafe flag set, they guessed wrong.  By continuing the game, they can learn your balance.

So it seems this does introduce a general information leak side channel.

I wonder if it is possible to limit the bandwidth of this channel enough to make the mechanism useful for good scenarios while very cumbersome for bad scenarios. 

e.g., perhaps we could have a rate-limiting timeout on violations in a given window or for a window + set of origins?  Perhaps we break the "no new security prompts" rule and show a modal warning dialog for ten seconds, or just force the user to close that tab/window, if we see multiple unsafe interactions within a short time period.  Not great, but I expect the signal from abuse of this kind of side channel would be pretty unambiguous, so the false positive rate would be very, very low.

Other ideas?

-Brad

> -----Original Message-----
> From: Peleus Uhley [mailto:puhley@adobe.com]
> Sent: Tuesday, May 28, 2013 4:31 PM
> To: public-webappsec@w3.org
> Subject: Cross-domain information leak with UI Security Directives
> 
> 	I was reviewing the UI Security Directives specification and I believe
> that I have identified a way that it can be used as a small cross-domain
> information leak.  Here is the overview:
> 
>                Attacker's goal: The owner of haxor.biz wants information about
> your browser's state with another domain. As one example, let's say
> haxor.biz wants to know what your anti-phishing security image is with your
> bank. (e.g. Your login page will always show a teddy bear so you know that
> you are at their site).
> 
>                Assumptions: Most security image implementation are based on a
> fixed number of pre-selected images. The owner of haxor.biz has
> downloaded all of them from the victim site.
> 
>                Method of attack: The victim visits haxor.biz. The site haxor.biz loads
> a child iframe from haxor.biz that has UI safety directives specified and a
> report-uri pointing back to haxor.biz. Within the UI protected frame,
> haxor.biz has an image tag which references the bank's security image CGI so
> that it will display the victim's security image.  The browser will take the
> initial screen shot based on this state.  Then the haxor.biz page will overlay
> the security image with what it believes the victim's security image to be.
> The display-time timeout will occur and another screen shot will be taken.
> The two screen shots will be compared.  If haxor.biz gets an error report to
> their report-uri, then they know that they have guessed wrong. If haxor.biz
> doesn't get an error-report, then they have guessed the victim's security
> image.
> 
>                In practice, I realize that the security image isn't the best example
> based on when they typically show up in a login work flow and the number of
> possible images. However, there could be simpler variants of this attack. For
> instance, if the attacker just wanted to know whether you are logged in, then
> they could try overlaying the "sign-in" vs "login" buttons of the victim
> website. This information could be useful in making CSRF attacks more
> accurate.
> 
>                Challenges for the attacker: Many sensitive web pages will have x-
> frame-options or CSP frame-options defined to prevent haxor.biz from
> loading their site in an iframe. The attacker would be limited by the fact that
> the content that is being tested would be visible to the end-user when the
> snapshot is being taken. Also, this attack wouldn't allow for an arbitrary read
> of the page contents. It would only allow the attacker to perform a
> true/false test on the user's session with another domain. The actual value of
> the information that is leaked would be site dependent.
> 
>             The primary concern with this issue is that it would be a by-default
> information leak in the browser that sites would have to take action to
> protect themselves against it. Do we think that this risk merits a change to
> the spec? Any additional ideas or concerns?
> 
> -Peleus
>

Received on Sunday, 2 June 2013 21:05:52 UTC