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.

Hello:

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

http://example.com/.well-known/ni/sha-256/f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

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.

Regards,
-- 
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.3.1 : Monday, 23 October 2017 14:54:08 UTC