W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2013

Re: Attempt to use CSP - Questions

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Fri, 20 Sep 2013 19:26:38 +0200
Message-ID: <523C854E.8060408@gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Brad,

Thanks, of course I do not intend to use it in production, while I was 
securing resources loading of the project I was just curious to try CSP, 
and looking at some FF/Chrome announcements it seemed that nonces were 
implemented.

Maybe I am wrong but I am not 100% convinced by the CSP statement saying 
that resources should not come inline and better be splitted into 
different urls, because the more you load things, the more you increase 
the risk of having what you are loading modified by an attacker, but 
probably both approaches have their pro and cons.

That's why I am not loading the code of the worker and I am using 
createObjectURL but the intention here was not to find an alternative to 
eval, I really need a worker.

Probably the group has already discussed the topic of "unsafe-eval to a 
set of urls", the problem in my example is that I am opening eval and 
inline scripts to Google (even if Google APIs are using eval, it should 
not apply to all whitelisted resources), why is it so hard to do?

I did not see the discussion about nonces being replaced by hash and 
about URL paths but will try to follow it, the ideas are interesting, I 
hope they will survive.

Regards,

Aymeric


Le 20/09/2013 18:40, Hill, Brad a écrit :
> (to WG members - see, people will totally try to use createObjectURL to get around eval restrictions! )
>
> Aymeric,
>
>    It looks as though you are trying to use features from CSP 1.1, like nonces and URL paths.  These features are still considered experimental at this time.  They will not be supported by default in most browsers, (in Chrome they are behind "experimental webkit features" in chrome://flags ) they may not survive to the final spec, (there is talk of replacing nonces with hashes) and there are no conformance tests for this yet.
>
>    So you're in uncharted waters, I'm afraid, for production code, though we are happy to hear your feedback.
>
>    In general eval and creating workers from blob: uris is unsafe. Because this involves creating code from strings, and we have no origin-tainting mechanism in browsers to understand where these strings came from, there is no way to meaningfully express a policy like "unsafe-eval only from example.com".
>
>    In current implementations for the createObjectURL -> Worker scenario, Firefox requires blob: to be explicitly listed as a scheme under script-src, and Chrome requires 'self' in script-src.  We are considering changing this behavior, not just because it is incompatible, but because it is insecure.  This behavior may be behind unsafe-eval or require explicit listing of blob: in the near future.
>
> -Brad Hill
>
>
>
>
>
>
>
>
>
>
>
> ________________________________________
> From: Aymeric Vitte [vitteaymeric@gmail.com]
> Sent: Friday, September 20, 2013 9:21 AM
> To: public-webappsec@w3.org
> Subject: Attempt to use CSP - Questions
>
> I tried to use CSP on FF and Chrome with the following use case :
>
> http://peersm.com :
> <style nonce="random">...</style>
> <img from http://www.peersm.com>
> <script src="https://peersm.com/script.js" nonce="random">
> <script google>
>
> script.js :
> xhr-->decrypt data --> eval(decrypted data)
> var workerjs='code';
> var worker=new Worker(URL.createObjectURL(new Blob([workerjs])));
> new WebSocket('ws://xxx:yyy')
>
> I ended up with the following CSP rule :
>
> head['Content-Security-Policy']= "default-src 'self'; img-src
> http://www.peersm.com; connect-src http://peersm.com xxx;style-src
> 'unsafe-inline'; script-src 'unsafe-eval' 'unsafe-inline'
> https://peersm.com https://www.google.com https://ajax.googleapis.com
> 'nonce-random';script-nonce random";
>
> Which seems completely insecure...
>
> 1- I could not make nonces work even using both syntaxes above, that's
> why https://peersm.com is in the script-src list and 'unsafe-inline' in
> style-src, reading at the docs it seems implemented but maybe it's not
> 2- I added 'unsafe-inline' in script-src since the worker as defined
> here is maybe assimilated to an inline script but whatever we do CSP
> blocks the worker
> 3- It's not clear depending on browsers if you can whitelist a complete
> url (http://a/b/c/script.js) or not (http://a/b/c) (working on Chrome,
> not working on FF)
>
> I have some doubts while reading the CSP spec, so sorry if the remarks
> have already been discussed. You might object that I am doing strange
> things but there are very good reasons for that, for example I can not
> load directly script.js inside https://peersm.com because FF will refuse
> to create a non SSL/TLS WebSocket (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=917829)
>
> What I would think natural to have is something like:
>
> style-src ('unsafe-inline' only with http://peersm.com/) or 'nonce-random'
> --> allow unsafe-inline only for a set of urls or use nonces
> script-src ('unsafe-eval' only with https://peersm.com/script.js)
> ('unsafe-inline' only with workers) https://www.google.com
> https://ajax.googleapis.com (https://peersm.com/script.js or 'nonce-random')
> --> allow unsafe-eval only for a set of urls, whitelist them explicitely
> or use nonces
>
> But as far as I understand the spec this is not possible, correct?
>
> Regards
>
> Aymeric
>
> --
> jCore
> Email :  avitte@jcore.fr
> Peersm : http://www.peersm.com
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>

-- 
jCore
Email :  avitte@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Friday, 20 September 2013 17:27:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC