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

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

From: Eduardo Robles Elvira <edulix@agoravoting.com>
Date: Thu, 20 Nov 2014 23:05:27 +0100
Message-ID: <CAHwZu3cVzJ4FzxONeGSM09Q3=3820LAg+FbePgCge8B9xuw0fw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Joel Weinberger <jww@chromium.org>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Oct 29, 2014 at 6:37 AM, Brian Smith <brian@briansmith.org> wrote:
> Consider this:
>     Content-Security-Policy: script-src http://example.com/foo.js
>     <script src='http://example.com/foo.js' integrity='ni:[digest]'>
>     <script src='http://example.com/foo.js'>
> The first <script> is an intended part of the page. The second script is
> injected with XSS. Thus, an XSS attack is able to undo the protection of SRI
> even when CSP is in place, and there is nothing you can do about it with
> CSP, *even* if you use a full path. That seems wrong. On the other hand,
> your server-side development framework should never have let the XSS
> happened in the first place, and CSP is the last line of defense, not the
> first.


Maybe I'm a bit late to this discussion, but what if the resource is
loaded via a .well-known ni uri. Example:


Then your CSP could just specify that uri to be allowed from that
domain. In that case, your browser could automatically detect that
it's a well-known ni uri and check it any time it's loaded.

Eduardo Robles Elvira     @edulix             skype: edulix2
http://agoravoting.org       @agoravoting     +34 634 571 634
Received on Thursday, 20 November 2014 22:06:24 UTC

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