- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sat, 8 Nov 2014 20:20:29 -0800
- To: Brian Smith <brian@briansmith.org>
- Cc: Joel Weinberger <jww@chromium.org>, Hatter Jiang OWS <hatter@openwebsecurity.org>, Ben Toews <btoews@github.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> Do you have a pointer to an explanation about why it is important for > SRI to not be part of CSP? I don't think SRI should not be part of CSP; I just don't think it should be part of CSP exclusively. I don't think anyone has written down any reasoning , but let me try list some reasons that I thought of right now :) I personally doubt the usability/deployability of listing a large number of hashes in a policy. I know I would prefer to list and use hashes inline. We haven't seen deployment of policies with large number of hashes. With stuff like non-canonical-src, there is some security relevant sensitive inline with the page still. For example, if the CDN server is haxored and there is XSS on the host page, then the CDN server could be told return malicious files, the hash (from CSP) won't match and the browser will host stuff from non-canonical-src (provided by attacker) which again means we are pwned. With Ajax navigation and history.pushState, document 'navigation' (which will reload CSP policies) is not necessary in a modern web app (like Ember, AngularJS apps). We haven't standardized on a mechanism for modification of CSP policies at runtime (and since the threat model you outline includes XSS, I am not sure we can do that safely), this means that the first page load will have to list all the hashes for scripts, styles, downloads (and more as we support more sub resource types) that could be used. I think it is far more usable to be able to get the hashes as part of the XHR fetch to get markup/json and include it when it is added to the page. thanks Dev
Received on Sunday, 9 November 2014 04:21:15 UTC