Re: CSP: setAttribute allows eval from string

Restricting eval isn't necessary to defend yourself from garden
variety XSS.  For example, in adding CSP policies to the HTML UI in
Chrome, we haven't yet gotten rid of all the eval calls, so we're
using unsafe-eval.  The policy still give us very strong XSS
protection because we haven't allowed unsafe-inline.

Adam


On Thu, Jun 16, 2011 at 2:04 PM, sird@rckc.at <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> wrote:
>> On Thu, Jun 16, 2011 at 12:34 PM, gaz Heyes <gazheyes@gmail.com> wrote:
>>> On 16 June 2011 18:55, Jarred Nicholls <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
>>
>

Received on Thursday, 16 June 2011 22:24:47 UTC