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

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

From: Mike West <mkwst@google.com>
Date: Mon, 7 Jul 2014 16:20:57 +0200
Message-ID: <CAKXHy=f30yXP-UCWm6eAeMnDCnRwxbDwYjjAQfxcw2=4vuY+KQ@mail.gmail.com>
To: Deian Stefan <deian@cs.stanford.edu>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, pamela fox <pamela.fox@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Mark Nottingham <mnot@mnot.net>
Though I share Michal's cynicism about the leakiness of the web in
general, I agree that we should be doing our best to plug leaks when
we can. CSP can and should make it non-trivial for attackers to
attack, even if it's unlikely that we can make it non-possible. :)

Both of the suggestions here (navigation and messaging) seem like
reasonable things to talk about in the context of CSP v.Next. I'll try
to pull together a backlog this week, as there are a number of these
good suggestions that might otherwise fall through the cracks (I'm
thinking of mnot@'s cookie proposal, for example).

-mike
--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Mon, Jul 7, 2014 at 3:59 PM, Deian Stefan <deian@cs.stanford.edu> wrote:
>
> 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.
>
> Cheers,
> Deian
Received on Monday, 7 July 2014 14:21:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC