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

no-external-navigation

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Thu, 8 Dec 2011 23:19:38 -0800
Message-ID: <CALx_OUDyFBKg0WsRV+PHD=LT9fzf67eHDkhpmvg0-1g+kpZzSQ@mail.gmail.com>
To: public-webappsec@w3.org
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 Friday, 9 December 2011 07:20:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 9 December 2011 07:20:32 GMT