Re: CSP - Prevent DOM XSS only?

Most likely not.

There's https://code.google.com/p/dominatrixss-csp/ which kindof does that
(with the problem I mentioned earlier of innerHTML still working for
attacks that happen before the page finishes loading) and requires us to
add a script to all pages (which is bad for network performance and
extremely hard to deploy).

Also, monkeypatching createElement/cloneNode/setAttribute/etc.. to add
nonces to remote scripts is also a bit hacky (because of this:
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#interaction-with-the-script-src-directive
).

The project mentioned earlier (https://code.google.com/p/dominatrixss-csp/)
is probably the best solution we have with the caveat that DOM XSS that
happens before the page finishes loading still happens, and that we need to
deploy a script to all pages we want to work with this.

I'm not sure what problem script-nonce was meant to solve tbh since so many
scripts load other scripts within them and asking the whole world to be CSP
aware is a bit hard.

In reality, what solving DOM XSS would mean in this context is that we want
the policy to only apply to stuff done by javascript, but that you trust
the HTML you are serving.

Maybe a:

Content-Security-Policy: for (all|static|dom)

which defines for what the CSP will apply to.


On Mon, Dec 10, 2012 at 2:52 PM, Mike West <mkwst@google.com> wrote:

> 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.
>>
>
>