Re: CSP - Prevent DOM XSS only?

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