RE: CSP: setAttribute allows eval from string

I'd disagree and say that:

1) I'm not ready to conclude that I can already tell what useful and interesting things people might be able to build with CSP, and that all inline script is a hopeless case.

(therefore...)

2) Disabling eval (and other features) in CSP should operate as "deep advice", that is, it should operate on the function itself, regardless of which access path is used for the call.    With ECMA Script 5, we can already do simple things like redefine eval() and set the new function as non-configurable.  What we have trouble doing is enumerating and disabling every possible alias to eval().

Philosophically, a CSP directive gives us a chance to provide advice directly to the scripting engine, before execution starts.  We should use that opportunity to enable things that are easy to do at that layer but are difficult or impossible from within the language itself.

-Brad

From: public-web-security-request@w3.org [mailto:public-web-security-request@w3.org] On Behalf Of Joel Howard Willis Weinberger
Sent: Thursday, June 16, 2011 2:42 PM
To: sird@rckc.at
Cc: Adam Barth; gaz Heyes; Jarred Nicholls; public-web-security@w3.org
Subject: Re: CSP: setAttribute allows eval from string

The theory at least is that even if you allow inline scripts, if you ban eval, that eliminates a class of attacks where an attacker can insert HTML sanitized code that says "eval(...)" (but because it was properly sanitized, they can't insert an inline script).

However, practically speaking, I agree with you, and as Adam said, "supplying unsafe-inline in your CSP policy basically
means you don't care about XSS".
--Joel
On Thu, Jun 16, 2011 at 2:04 PM, sird@rckc.at<mailto:sird@rckc.at> <sird@rckc.at<mailto:sird@rckc.at>> wrote:
What is the rationale behind having 2 options?

inline-script and eval-script

Via inline-script you can simulate an eval-script.

Via eval-script you can simulate an inline-script.


-- Eduardo




On Thu, Jun 16, 2011 at 4:01 PM, Adam Barth <w3c@adambarth.com<mailto:w3c@adambarth.com>> wrote:
> On Thu, Jun 16, 2011 at 12:34 PM, gaz Heyes <gazheyes@gmail.com<mailto:gazheyes@gmail.com>> wrote:
>> On 16 June 2011 18:55, Jarred Nicholls <jarred@sencha.com<mailto:jarred@sencha.com>> wrote:
>>> I'm not following, why would there be a difference in treatment between
>>> DOM access and the parser?
>>
>> Normally string data isn't accepted with an event specified in the DOM. So
>> something like:-
>> document.getElementById('x').onclick=function(){};
>>
>> So I thought since CSP disables eval, setTimeout etc setAttribute should be
>> included because it converts string data into JavaScript code. For example:-
>> document.getElementById('x').setAttribute('onclick','alert(1)');
>>
>> You obviously all don't agree and that's fine
>
> My sense is that supplying unsafe-inline in your CSP policy basically
> means you don't care about XSS, so I'm not that worried about this
> vector.
>
> Adam
>