W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

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

From: Michal Zalewski <lcamtuf@dione.cc>
Date: Mon, 29 Sep 2008 13:41:59 +0200 (CEST)
Message-ID: <Pine.LNX.4.64.0809291328410.10659@dione.cc>
On Mon, 29 Sep 2008, Hallvord R M Steen wrote:

> To give webmasters more ways to deal with this situation, I think we 
> should implement the Access Control "Origin" HTTP-header only (assuming 
> that it should refer to the top site in the frameset hierarchy).

I definitely like the "Origin" proposal the most of all the opt-in 
schemes, simply because it permits trusted domains to be whitelisted for 
many applications that rely on same-origin separation to implement 
security sandboxes.

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.

Note that the current implementation proposals for "Origin" headers (which 
I believe are limited to non-GET, non-HEAD requests) would not prevent 
this attack, nor some other potential attack vectors; they would probably 
need to be modified to include "Origin" header on SRC= GET requests on 
IFRAME / EMBED / OBJECT / APPLET.

Extending the scheme to include SCRIPT would also cover script-inclusion 
attacks; extending it to all automated navigation (SRC=, REL=, scripted 
form submissions and location updates, etc) would prevent a broader set of 
XSRF and XSS attacks than the original proposal, but that's purely 
optional. But the bottom line is, there are some extra birds we could hit 
with that stone.

> 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

As noted, one important scenario which we do not account for is "5. anyone 
may iframe my content, but I want my UI not to get clobbered". This would 
realistically be the expectation for almost any privileged / authenticated 
gadget to be embedded on third-party pages.

Cheers,
/mz
Received on Monday, 29 September 2008 04:41:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC