On 4/4/09 2:15 PM, Florian Weimer wrote:
There's also the question if this approach just moves the cross-site scripting risk to direct injection into Javascript code. The proposal does not really address this (which is not its fault), but CSP restrictions might lead developers to rely increasingly on Javascript code generation to add HTML attributes which are blocked.
Maybe I don't fully understand your concern, but I don't think we're just shifting the attacks; many sites use the JavaScript-to-attach-handlers technique already, and we're not enforcing this policy for all sites -- just the ones who want to use CSP, and only because we need to do this to be sure the policies are properly enforced.
Also, one of the desired features of CSP would be not only this load-time blocking of the methods/attributes that make code from strings, but also run-time enforcement too. The attributes that are blocked by CSP at load-time are also not allowed to be added to the DOM at run-time. So you can't just put "domElement.onclick = 'myArbitrary(function) {foo}';" into javascript, no code-from-strings conversion is allowed at any time. An attacker has to inject actual code into a site, and not just exploit an "eval()" or other string-to-code conversion in the developer's JavaScript.
It's my belief that CSP will generally make attacks more difficult and vulnerabilities harder to come by, not just different. In order to get the on-click event handler to work, for instance, the developer has to place an event handler function somewhere in the white-listed script file and use JavaScript to attach it to DOM. The only obvious way an attacker could inject different event handling code is through a MITM attack or a direct injection to the server's data store that messes with the JavaScript content being served. Since CSP is stopping JavaScript from making code out of strings in the browser, the attacker must inject stuff on the server side or in the network stream, and if he can do that, it's game over anyway.
-Sid _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
