- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 18 Feb 2009 11:43:14 +0000 (UTC)
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? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 18 February 2009 03:43:14 UTC