RE: CSP Sandbox directive and meta tag - CSP 1.1

Agreed. If there is an XSS in the title-tag (which is a place many of the
bigger sql injection worms have placed payloads) and the meta tag comes
after it, the page is still hosed.
And if I remember correctly it's using http-equiv which as a developer
leads me to believe the header and meta tag behave the same way...

Erlend
------------------------------
From: Jacob Rossi
Sent: 19.09.2012 03:52
To: Devdatta Akhawe
Cc: Tanvi Vyas; public-webappsec@w3.org
Subject: RE: CSP Sandbox directive and meta tag - CSP 1.1

    >> And Jacob's mail shows that
Microsoft might also be able to support sandbox in meta tag

No, my mail does not. We have not evaluated what it would take to make
sandboxing flags mutable during parsing.

>>And in
terms of security, it makes sense to have a document specify "ok I am
done with my privileged stuff , please drop my privileges now"

This encourages bad practices, such as putting scripts in the head of your
document.
 ------------------------------
From: Devdatta Akhawe
Sent: 9/18/2012 6:09 PM
To: Jacob Rossi
Cc: Tanvi Vyas; public-webappsec@w3.org
Subject: Re: CSP Sandbox directive and meta tag - CSP 1.1

 I think meta tag should have sandbox support. First, I dislike "some
options only work in header". Further, WebKit (correct me here)
already supports meta tag sandbox. And Jacob's mail shows that
Microsoft might also be able to support sandbox in meta tag. And in
terms of security, it makes sense to have a document specify "ok I am
done with my privileged stuff , please drop my privileges now"

> 1. The spec describes that HTTP headers trump meta tags, the first meta
tag wins over subsequent ones, and that meta elements inserted after
loading are ignored. But what about dynamic manipulation of a currently
enforced policy from a meta element? In other words, can I alter the
content attribute of the meta tag after loading the document?  I think the
answer should be no, but that should probably be specified.
>

+1

> 2. I assume that, prior to parsing the meta element, scripts can execute
as though there is no policy. So:
>
> <script> alert('You see this alert');</script>
> <meta http-equiv="content-security-policy" content="script-src: 'none'">
> <script> alert('You will not see this alert');</script>
>
> But what if this was a plugin?  Does the first plugin get unloaded by the
User Agent or does the later loaded policy not apply to it?
>

I think not applying to it makes sense.



thanks
Dev

> Thanks!
>
> -Jacob
>
> -----Original Message-----
> From: Tanvi Vyas [mailto:tanvi@mozilla.com <tanvi@mozilla.com>]
> Sent: Tuesday, September 18, 2012 3:17 PM
> To: public-webappsec@w3.org
> Subject: CSP Sandbox directive and meta tag - CSP 1.1
>
> A couple months ago during our biweekly call we discussed how a csp
sandbox directive would be handled when the content security policy is
specified in a meta tag.  We proposed ignoring the csp sandbox directive if
set in a meta policy.  This is because the sandbox flag needs to be set on
navigation, and the <meta> tag with the policy isn't specified until after
navigation and after a principal for the document has already been set.
Switching to the null principal after we discover the sandbox directive
makes following the same origin policy tricky since we'd already be halfway
through parsing the document.
>
> Bringing this up on the mailing list for further discussion. Thanks!
>
> ~Tanvi
>
>
>
>
>
>