RE: Attempt to use CSP - Questions

(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

Received on Friday, 20 September 2013 16:41:05 UTC