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

Hey Mike,

Following up on this, is there anything that I can do to help with
trying to make this real?

Thanks,
Deian

Mike West <mkwst@google.com> writes:

> 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