Re: webappsec-ISSUE-56 (child src navigation): Should we restrict subsequent navigation within child-src? [CSP 1.1]

I suspect that we do indeed want to cover things like redirects, which is
generally where the problems that post outlines crop up.

I'd also suggest that `child-src` isn't really the core of that article's
attack vector, but `img-src`, where we definitely want to cover redirects.

-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 Tue, Jan 14, 2014 at 11:36 PM, Web Application Security Working Group
Issue Tracker <sysbot+tracker@w3.org> wrote:

> webappsec-ISSUE-56 (child src navigation): Should we restrict subsequent
> navigation within child-src? [CSP 1.1]
>
> http://www.w3.org/2011/webappsec/track/issues/56
>
> Raised by: Brad Hill
> On product: CSP 1.1
>
> We use CSP to govern creation of child browsing contexts of various types.
>  It makes sense to prevent inline content from creating such links, or from
> navigating a sub-context itself.
>
> Does it make sense to prevent the new context from navigating itself?
>  This is a bit odd, not sure what threats it protects against, and creates
> some information leakage risks:
>
>
> http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html
>
> Could we say that frame-src and similar govern only the initial value and
> parent navigation of the frame, not its own self-navigation?
>
>
>
>