- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 12 Dec 2011 14:31:05 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: public-webappsec@w3.org
I've add this to the wiki for consideration in CSP 1.1. Adam 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