W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2011

Re: no-external-navigation

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 12 Dec 2011 14:31:05 -0800
Message-ID: <CAJE5ia-kEQzD36mrMGXTv5koNhEoeSo6AZTW5J1B9o-E3HWTGg@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: public-webappsec@w3.org
I've add this to the wiki for consideration in CSP 1.1.


On Thu, Dec 8, 2011 at 11:19 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
> Hi folks,
> It is well-known that if you are in possession of a JavaScript handle
> of another non-same-origin window, you can navigate it to an arbitrary
> URL by leveraging location.*, window.open(), history.*, HTML target=,
> etc.
> What is perhaps less obvious is that by leveraging pseudo-URLs or
> pre-cached content, this can be done seamlessly, and in a manner that
> is practically imperceptible even to attentive users. See this
> proof-of-concept for a quick demo:
> http://lcamtuf.coredump.cx/switch/
> I think that behavior is very problematic; I can elaborate, but I'm
> hoping the issue here is obvious.
> I can't think of a realistic on-by-default solution, but a potential
> opt-in approach is to allow websites to specify that they want to be
> immune to external, non-same-origin attempts to navigate their
> document window. This could be implemented as a CSP directive or a
> standalone HTTP header (say, X-External-Navigation: deny).
> Of course, the restriction should not apply to any navigation
> initiated manually by the user through the address bar, bookmarks,
> etc.
> Does this make sense? If yes, the setting probably needs to be honored
> only on the top-level document for simplicity. Protecting frames may
> have some fringe benefits (in the few cases not covered by the
> descendant policy), but may also have drawbacks.
> /mz
Received on Tuesday, 13 December 2011 03:46:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:26 UTC