- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 26 Sep 2013 11:37:23 +0200
- To: Aymeric Vitte <vitteaymeric@gmail.com>, public-webappsec@w3.org
Le 20/09/2013 18:21, Aymeric Vitte a écrit : > 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) Firefox blocks mixed content. See https://developer.mozilla.org/en-US/docs/Security/MixedContent The idea is that if you deliver an HTTPS page, you expect security guarantees. You expect your users to expect them as well. If the browser loads HTTP resources, these are subject to MITM attacks, thus un-securing the secure channel you set up with HTTPS. So if you start with HTTPS, be secure all the way, otherwise, you're giving to your users a false sense of security. > 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? I don't think it is, but I also don't think you need any of that. CSP allows you to choose initial sources. Which authority you want to provide afterwards (eval) is up to you. More precisely, it's up to the policy your describe as code in the whitelisted sources. I don't understand the idea of per-domain unsafe-inline whitelists. If something is inline (<style> <script>), it's in your HTML page, there is no notion of domain. David
Received on Thursday, 26 September 2013 09:37:52 UTC