- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 19 Jul 2012 13:21:00 -0700
- 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 UTC