W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: CSP: 'no-external-navigation'?

From: Deian Stefan <deian@cs.stanford.edu>
Date: Mon, 07 Jul 2014 06:59:35 -0700
To: Michal Zalewski <lcamtuf@coredump.cx>, pamela fox <pamela.fox@gmail.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
Message-ID: <87vbr946d4.fsf@cs.stanford.edu>

Hi Michal,

Michal Zalewski <lcamtuf@coredump.cx> writes:

>> I think it's both. If we can prevent the exfiltration of data, we can also
>> prevent phishing attacks.
> Well, not per se - you still allow scripts that may ask the users for
> their credentials and such; you're just hoping that they won't be able
> to hand these over to a remote server or other document, right?
> Unfortunately, the latter, I think, is probably ~impossible :-(
> postMessage() is just one example, but there is a multitude of ways
> that JavaScript in a sandbox can communicate with the outside world
> without navigation or direct requests; for example, it's fairly
> straightforward to relay messages by modulating CPU load, by putting
> them in window.name or similar places, etc. There have been quite a
> few academic papers that hinged on the assumption that such side
> channels do not exist or can be suppressed reliably, but I haven't seen
> anything that would seem realistic, TBH :-(
> ( In fact, the earliest experiment back in Netscape Navigator days is
> probably http://docstore.mik.ua/orelly/web/jscript/ch20_04.html )

I agree that trying to address (certain) covert channels in the
browser is not really a practical problem. However, what Pamela is
bringing up and what we are also interested in is addressing (some) overt
channels. Navigation for sandboxed iframes and postMessage are pretty
reasonable things to think about. (In Gecko, and I suspect Blink, even
window.name is very much an overt channel.) Moreover, having control
over navigation and explicit messaging would serve useful even if only
used as a defense-in-depth. (If I am not mistaken, this is how Pamela is
also trying to use this.)

For postMessage, the proposed message-src attribute would give
developers just this, an additional protection layer over the per-call
destination-origin argument.  If I set a CSP header saying that the
only domains I am okay with sending a postMessage to are X, Y, and Z,
now I don't need to worry so much about another developer (on my team,
but less concerned about security) setting (or rather forgetting to set)
the correct destination origin.


Received on Monday, 7 July 2014 15:45:57 UTC

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