- From: Eduardo Robles Elvira <edulix@agoravoting.com>
- Date: Thu, 20 Nov 2014 23:05:27 +0100
- 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