[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Giorgio Maone]

Ian Hickson wrote, On 18/02/2009 12.43:
>> 3) Add an on-by-default mechanism that prevents UI actions to be taken
>>    when a document tries to obstruct portions of a non-same-origin frame.
>>    By carefully designing the mechanism, we can prevent legitimate uses
>>    (such as dynamic menus that overlap with advertisements, gadgets, etc)
>>    from being affected, yet achieve a high reliability in stopping
>>    attacks.
>>     
>
> This seems difficult to get right in practice, and browser vendors seem 
> reluctant to go down this road.
Incidentally, NoScript's ClearClick is a working implementation of this 
"difficult" approach, effective also with same-origin plugin content 
(like in the original Clickjacking PoC by RSnake & Grossman).
http://noscript.net/faq#clearclick
-- G

Ian Hickson wrote, On 18/02/2009 12.43:
> On Thu, 25 Sep 2008, Michal Zalewski wrote:
>   
>> Problem definition: a malicious page in domain A may create an IFRAME 
>> pointing to an application in domain B, to which the user is currently 
>> authenticated with cookies. The top-level page may then cover portions 
>> of the IFRAME with other visual elements to seamlessly hide everything 
>> but a single UI button in domain B, such as "delete all items", "click 
>> to add Bob as a friend", etc. It may then provide own, misleading UI 
>> that implies that the button serves a different purpose and is a part of 
>> site A, inviting the user to click it. Although the examples above are 
>> naive, this is clearly a problem for a good number of modern, complex 
>> web applications.
>>
>> Proposed fixes:
>>
>> 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
>>    "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web
>>    page to inhibit frame rendering in potentially dangerous situations.
>>
>>    Pros:
>>
>>    - Super-simple
>>
>>    Cons:
>>
>>    - "Opt-in", i.e. currently vulnerable sites remain vulnerable unless
>>      action is taken
>>
>>    - Can't be used for cases where IFRAME content mixing has a legitimate
>>      purpose (for example, cross-domain gadgets, certain types of mashups)
>>     
>
> In particular, this breaks Image Search tools from various vendors as well 
> as navigation aids like the Reddit toolbar.
>
>   
>>    - Adds yet another security measure (along with cross-domain XHR, MSIE8
>>      XSS filters, MSIE P3P cookie behavior, Mozilla security policies)
>>      that needs to be employed correctly everywhere to work - which is
>>      very unlikely to consistently happen in practice
>>
>>    - Along with the aforementioned security features, threatens to
>>      result in HTTP header or HTML HTTP-EQUIV size bloat that some sites
>>      may care about.
>>     
>
> This solution is what IE8 has apparently chosen to use.
>
> Specifically, IE8 will recognise an HTTP header or <meta> pragma directive 
> with the name "X-Frame-Options", and will process it as follows:
>
>    If the value is a case-insensitive match for "deny" and the browsing 
>    context being navigated is not a top-level browsing context, replace 
>    the document with a UA-defined error message.
>
>    If the value is a case-insensitive match for "sameorigin" and the
>    browsing context being navigated is not a top-level browsing context 
>    and the origin of the top-level browsing context is not the same as the 
>    origin of the document in question, replace the document with a 
>    UA-defined error message.
>
> (The "sameorigin" rule seems like it should check all ancestor browsing 
> contexts, not just the top-level one, because otherwise a site X, e.g. 
> images.google.com, showing a frame with a document on site Y, e.g. 
> hostile.example.com -- which might happen e.g. on something like Google 
> Image Search -- would be able to embed another page from site X, e.g. your 
> image search preferences, and do clickjacking on it.)
>
> This feature could also be extended to apply to other resources, e.g. 
> scripts, images, style sheets, fonts, to prevent them from being used 
> cross-origin. This would help, e.g., with securing scripts that contain 
> private data.
>
>
>   
>> 2) Add a document-level mechanism to make "if nested <show this> else
>>    <show that>" conditionals possible without Javascript. One proposal is
>>    to do this on the level of CSS (by using either the media-dependency
>>    features of CSS or special classes); another is to introduce new HTML
>>    tags. This would make it possible for pages to defend themselves even
>>    in environments where Javascript is disabled or limited.
>>     
>
> This is an interesting idea, though it would be subsumed by Hallvord's 
> suggestion with Origin given below, in conjunction with idea 1 above in 
> the absence of Origin information.
>
>
>   
>> 3) Add an on-by-default mechanism that prevents UI actions to be taken
>>    when a document tries to obstruct portions of a non-same-origin frame.
>>    By carefully designing the mechanism, we can prevent legitimate uses
>>    (such as dynamic menus that overlap with advertisements, gadgets, etc)
>>    from being affected, yet achieve a high reliability in stopping
>>    attacks.
>>     
>
> This seems difficult to get right in practice, and browser vendors seem 
> reluctant to go down this road.
>
>
>   
>> 4) Enforce a click-to-work mechanism (resembling the Eolas patent
>>    workaround) for all cross-domain IFRAMEs.
>>     
>
> Experience with the Eolas patent workaround suggests this wouldn't be 
> popular, to put in mildly.
>
>
>   
>> 5) Rework everything we know about HTML / browser security models to
>>    make it possible for domains and pages to specify very specific opt-in
>>    / opt-out policies for all types of linking, referencing, such that
>>    countering UI redress attacks would be just one of the cases controlled
>>    by this mechanism.
>>     
>
> This seems like it would still basically need one of the other mechanisms 
> as well. Without a more concrete proposal here it's hard to tell what 
> exactly this would be.
>
>
> On Thu, 25 Sep 2008, Collin Jackson wrote:
>   
>> 6) New cookie attribute: The "httpOnly" cookie flag allows sites to put 
>> restrictions on how a cookie can be accessed. We could allow a new flag 
>> to be specified in the Set-Cookie header that is designed to prevent 
>> CSRF and "UI redress" attacks. If a cookie is set with a "sameOrigin" 
>> flag, we could prevent that cookie from being sent on HTTP requests that 
>> are initiated by other origins, or were made by frames with ancestors of 
>> other origins. In a CSRF or "UI redress" attack scenario, it will appear 
>> as though the user is not logged in, and thus the HTTP request will be 
>> unable to affect the user's account.
>>     
>
> This is an interesting idea, though it only works for Cookie- 
> authenticated content (admittedly that is most content). I recommend 
> suggesting this to the group currently speccing httpOnly. It seems out of 
> scope for HTML5.
>
>
>   
>> 7) New HTTP request header: Browser vendors seem to be moving away
>> from "same origin restrictions" towards "verifiable origin labels"
>> that let the site decide whether two security origins trust each
>> other.  Recent examples of this are MessageEvent's "origin" property
>> [1], postMessage's "targetOrigin" argument [2], and the HTTP "Origin"
>> header [3] [4] [5]. We can adjust proposal (1) to conform to this
>> philosophy: instead of making it an
>> "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP response
>> header, make it an "X-Ancestor-Frame-Origin: http://www.evil.com" HTTP
>> request header. This header could be a list of all the origins that
>> are ancestors of the frame that triggered the request. If the site
>> decides it does not like the ancestor frame origin it could reject the
>> request. This could be added as a property of MessageEvent as well to
>> detect client-side-only UI redress attacks.
>>     
>
> This could be considered an extension to suggestion 1.
>
>
> On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
>   
>> Sites may want to use any of several policies in a "somebody framed me" 
>> situation. For example, these are all policies a site may want to 
>> deploy:
>>
>> 1. nobody may frame my content
>> 2. selected sites only may frame my content
>> 3. anyone may frame my content but not re-use an existing session
>> 4. anyone may frame my content
>>     
>
> Also noted in other e-mails was:
>
>   5. anyone may frame my content, but I want my UI not to get clobbered
>
>
>   
>> Giving the site an "Origin: http://www.example.com" HTTP header in the 
>> intial request lets the backend implement any of these policies.
>>     
>
> (Except 5.)
>
>
>   
>> Instead of responding with a payload that always includes some variant 
>> of the proposed "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" 
>> header, the site can send or redirect to a framebreaking "embedding 
>> forbidden" page for policy #1. It can do so selectively based on origin 
>> site and/or requested content for policy #2. It can kill existing 
>> cookies, void session and set new origin-specific cookies for policy 
>> #3.)
>>     
>
> This is a good point. Maybe Adam's Origin draft can help with this? Adam?
>
> This wouldn't reduce the need for the other proposals, though, so that we 
> had defense in depth (e.g. for the cases where Origin was stripped, or for 
> servers that don't want to do dynamic work like this).
>
>
> On Mon, 29 Sep 2008, Michal Zalewski wrote:
>   
>> It still completely ignores the question of how we protect gadgets / 
>> mashups / whatever that are *designed* to be embedded on potentially 
>> untrusted sites, but depend on having the integrity of their UIs 
>> preserved, so I think we need - or well, should - tackle this aspect 
>> separately if this is the consensus for now.
>>     
>
> I have unfortunately not seen any workable solutions suggested for how to 
> solve this, and have no ideas myself.
>
>
> [snip a very long thread -- I did read every e-mail on this thread, and 
> these e-mails informed my comments in this e-mail]
>
>
> It seems like the most obvious course of action is to embrace Microsoft's 
> X-Frame-Options header, and consider extensions to make it apply to all 
> content and/or to make it support CORS headers also in the future.
>
> I would be interested in feedback from browser vendors about the 
> feasibility of such an approach.
>
> Is this something we should add to HTML5?
>
> I am interested also in suggestions on how to handle the <meta http-equiv> 
> pragma case, where the header can come megabytes into the file. Is it 
> acceptable to replace the document in-place once the pragma is seen and 
> found to deny embedding?
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090218/83f0f24e/attachment.htm>