W3C home > Mailing lists > Public > public-web-security@w3.org > December 2012

Re: CSP - Prevent DOM XSS only?

From: gaz Heyes <gazheyes@gmail.com>
Date: Mon, 10 Dec 2012 20:41:28 +0000
Message-ID: <CADJi-inaQ6rugPWmMV5iCP7Gz8yLJ7awe95HwzcqZTH5phU9Mg@mail.gmail.com>
To: "Eduardo' Vela" <evn@google.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>, Adam Barth <w3c@adambarth.com>
Why is this CSP's problem? Simply using defineProperty etc and overwrite
functions should solve this problem. I've started work on this already by
providing a environment that allows you to do basic non-destructive
behaviour using ES5.

<http://businessinfo.co.uk/labs/MentalJS/MentalJS.html>

For a demo..
1. Click Load jQuery.
2. Then enter:
b=document.createElement('b');b.appendChild(document.createTextNode('hello
world!'));document.querySelector('form').appendChild(b);
3. Click Execute.

This isn't a perfect environment yet, there are flaws and the js parse
times need to be improved but I think you can do all this without needing a
new CSP rule.

On 9 December 2012 01:57, 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:41:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 December 2012 20:41:57 GMT