<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ian Hickson wrote, On 18/02/2009 12.43:
<blockquote type="cite">
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This seems difficult to get right in practice, and browser vendors seem 
reluctant to go down this road.</pre>
</blockquote>
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 &amp; Grossman).<br>
<a class="moz-txt-link-freetext" href="http://noscript.net/faq#clearclick">http://noscript.net/faq#clearclick</a><br>
-- G<br>
<br>
Ian Hickson wrote, On 18/02/2009 12.43:
<blockquote
 cite="mid:Pine.LNX.4.62.0902180538490.6209@hixie.dreamhostps.com"
 type="cite">
  <pre wrap="">On Thu, 25 Sep 2008, Michal Zalewski wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
In particular, this breaks Image Search tools from various vendors as well 
as navigation aids like the Reddit toolbar.

  </pre>
  <blockquote type="cite">
    <pre wrap="">   - 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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This solution is what IE8 has apparently chosen to use.

Specifically, IE8 will recognise an HTTP header or &lt;meta&gt; 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.


  </pre>
  <blockquote type="cite">
    <pre wrap="">2) Add a document-level mechanism to make "if nested &lt;show this&gt; else
   &lt;show that&gt;" 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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.


  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This seems difficult to get right in practice, and browser vendors seem 
reluctant to go down this road.


  </pre>
  <blockquote type="cite">
    <pre wrap="">4) Enforce a click-to-work mechanism (resembling the Eolas patent
   workaround) for all cross-domain IFRAMEs.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Experience with the Eolas patent workaround suggests this wouldn't be 
popular, to put in mildly.


  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.


  </pre>
  <blockquote type="cite">
    <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://www.evil.com">http://www.evil.com</a>" 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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This could be considered an extension to suggestion 1.


On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Also noted in other e-mails was:

  5. anyone may frame my content, but I want my UI not to get clobbered


  </pre>
  <blockquote type="cite">
    <pre wrap="">Giving the site an "Origin: <a class="moz-txt-link-freetext" href="http://www.example.com">http://www.example.com</a>" HTTP header in the 
intial request lets the backend implement any of these policies.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
(Except 5.)


  </pre>
  <blockquote type="cite">
    <pre wrap="">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.)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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 &lt;meta http-equiv&gt; 
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?

  </pre>
</blockquote>
<br>
</body>
</html>