Re: CSP - Prevent DOM XSS only?

The goal of the `script-nonce` directive is to handle at least some of this
use-case:
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-nonce--experimental

Rather than altering the behavior of `innerHTML`, it asks developers to tag
inline script blocks that are intentionally included with a unique key,
generated on the fly for each request. Bad for caching, not particularly
useful for static sites, but useful for the (many?) applications that can't
kill inline scripts.

Would that suit your requirements?

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91



On Sun, Dec 9, 2012 at 2:57 AM, Eduardo' Vela <evn@google.com> wrote:

> Hi!
>
> For some pages (think, static content, or heavy JS sites), the only risk
> of XSS is DOM XSS, and one can't realistically convert all inline scripts
> to outline for performance reasons.
>
> ATM the only way to protect these pages is by creating the CSP header when
> the document finished loading (after onload or so), however that won't
> catch the scripts that are created before load time, like
> <script>xx.innerHTML=xxx</script>
>
> I want to propose something, maybe for CSP 1.1, 1.2, 1.x 2.x or whatever,
> that allows us to disable the behavior that makes innerHTML introduce XSS
> (and so, make innerHTML safe by default).
>
> Of course the same has to be done to insertAdjacentHTML, outerHTML, etc..
> but the idea still holds.
>
> It's unclear to me how to define an API for this, but here's a stab:
>  * script-src unsafe-static-inline
>  *  document.write/innerHTML/etc.. won't execute scripts.
>
> In the future one could expand the syntax to only allow "safe" strings or
> "untainted" strings.. but I don't want to go into details about that.
>
> The objective of this thread is to ignite discussion and flaming, I don't
> realistically expect everyone to agree on something any time soon.
>

Received on Monday, 10 December 2012 20:53:01 UTC