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

Re: Secure dynamic JS compilation under CSP

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Thu, 19 Jul 2012 12:48:36 -0700
Message-ID: <CAFAtnWzx-LrLz47-LBpdRO3jzijq6-vwSKiRJs-0Av022BFwiw@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-webappsec@w3.org
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()?

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.

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.

jjb

>
> 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 19:49:04 GMT

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