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