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

Re: CSP - Prevent DOM XSS only?

From: Eduardo' Vela <evn@google.com>
Date: Mon, 10 Dec 2012 14:44:48 -0600
Message-ID: <CAFswPa8Pgh9hM1b2qJvzDPxp6PxsqWrasLrZs8HVKX_srmgzaQ@mail.gmail.com>
To: gaz Heyes <gazheyes@gmail.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>, Adam Barth <w3c@adambarth.com>
Well, mostly because we can define this as a policy to a large set of
products without having to include a large JS file rather than a hack with
the JS environment :)

On Mon, Dec 10, 2012 at 2:41 PM, gaz Heyes <gazheyes@gmail.com> wrote:

> 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:46:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:20 UTC