W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

Cross-domain information leak with UI Security Directives

From: Peleus Uhley <puhley@adobe.com>
Date: Tue, 28 May 2013 16:31:16 -0700
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <89C32933AB7E6E4C89818D91F8FDC25F386BABA253@nambxv01a.corp.adobe.com>
	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?

Received on Tuesday, 28 May 2013 23:34:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC