- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 19 Jul 2012 22:31:58 +0200
- To: Adam Barth <w3c@adambarth.com>
- CC: John J Barton <johnjbarton@johnjbarton.com>, public-webappsec@w3.org
Le 19/07/2012 22:21, Adam Barth a écrit : > On Thu, Jul 19, 2012 at 12:48 PM, John J Barton > <johnjbarton@johnjbarton.com> wrote: >> 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. I'm glad to learn eval can be re-enabled. > 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. Backward compat aside, I disagree. If the scripting security model could be revised, I would make the exact same choice than the Chrome Extensions did, specifically disabling eval&friends by default (but enabling as opt-in) as well as disabling inline scripts which are an awful feature from the security point of view, because it's basically saying to any attacker "drop your script, I'll execute it anyhow". David
Received on Thursday, 19 July 2012 20:33:17 UTC