- From: Giorgio Maone <g.maone@informaction.com>
- Date: Wed, 18 Feb 2009 13:07:48 +0100
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>
Received on Wednesday, 18 February 2009 04:07:48 UTC