W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [SRI] To trust or not to trust a CDN

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 8 Nov 2014 20:20:29 -0800
Message-ID: <CAPfop_3wzPKOHFaJ6gfNjuA89JkAB6M3d7EpoKvV=514dHmy4A@mail.gmail.com>
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.

Received on Sunday, 9 November 2014 04:21:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC