W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2012

Re: Secure dynamic JS compilation under CSP

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 19 Jul 2012 13:21:00 -0700
Message-ID: <CAJE5ia-mR3iTgZvLtN8b2tN_JwQL6ZpjV-xP=We3HyhPonT0Ow@mail.gmail.com>
To: John J Barton <johnjbarton@johnjbarton.com>
Cc: public-webappsec@w3.org
On Thu, Jul 19, 2012 at 12:48 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> On Thu, Jul 19, 2012 at 12:24 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Thu, Jul 19, 2012 at 11:17 AM, John J Barton
>> <johnjbarton@johnjbarton.com> wrote:
>> > On Thu, Jul 19, 2012 at 10:54 AM, Adam Barth <w3c@adambarth.com> wrote:
>> >> If you want to use eval, you can enable it by listing 'unsafe-eval'
>> >> (with the quotes) in the script-src part of your CSP policy:
>> >>
>> >> default-src 'self'; script-src 'self' 'unsafe-eval'
>> >
>> > Thanks for the suggestion. However this option does not seem to be
>> > allowed
>> > for Chrome extensions:
>> > http://code.google.com/chrome/extensions/contentSecurityPolicy.html#H2-3
>>
>> Correct.  Chrome extensions limit the sorts of CSP policies you can use.
>>
>> > Any other suggestions?
>>
>> I'd recommend asking on the Chrome Extensions mailing list.  I'll be
>> happy to answer your questions there.  :)
>>
>> > By the way I object to the name of this option. "unsafe-eval" implies
>> > that
>> > eval is unsafe or that the CSP user intends to use eval in an unsafe
>> > manner.
>> > Neither of these is true for any practical users of CSP.  The problem is
>> > not
>> > eval(), it is inadequate vetting of content obtained over the network.
>>
>> Empirically, use of eval is unsafe.  According to a recent study
>> conducted before the migration to mainfest_version 2, about 1% of
>> Chrome Extensions contained XSS because of their use of eval.
>
> Are you sure about your interpretation of these observations?  Could an
> alternative interpretation be : about 1% of Chrome Extensions contained
> XSS because they allowed un-vetted content to enter their application and
> subsequently used that content in eval()?

That's also a valid interpretation of the data.

> My point is that eval() is not intrinsically unsafe. The ultimate problem is
> failure of network security. Removing eval() because the network is
> insecure makes the platform weaker. We should -- as CSP does in other
> ways -- make the network more secure.

That's why Content-Security-Policy, as a whole, gives developers the
option of whether to take the risk of enabling eval for their site.
We use the term 'unsafe-eval' to indiciate that enabling this feature
does introduce some amount of risk.  In Chrome Extensions, we've
adopted a stricter policy than is appropriate for the web at large.

> I gather that Chrome Extensions could have a CSP policy that prevents
> cross-site loads but allows eval().  I'll take that up  on the other list.

Thanks.

Adam


>> >> On Thu, Jul 19, 2012 at 10:45 AM, John J Barton
>> >> <johnjbarton@johnjbarton.com> wrote:
>> >> > Hi. I was looking into converting my application to use CSP when I
>> >> > learned
>> >> > that neither eval nor new Function() are allowed. I have a large
>> >> > application
>> >> > that uses these features to compile JS at runtime. I am wondering
>> >> > what
>> >> > alternatives are available.
>> >> >
>> >> > Thanks,
>> >> > jjb
>> >
>> >
>
>
Received on Thursday, 19 July 2012 20:22:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 20:22:49 GMT