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?
