HTML Subresource Integrity

Posted Jul 5, 2016 12:18 UTC (Tue) by excors (subscriber, #95769)
In reply to: HTML Subresource Integrity by paulj
Parent article: HTML Subresource Integrity

b.com could return HTTP headers that forbid caching, and assume that all caches between the server and user will respect those headers. (A browser that used the SRI hash as the cache key would never contact b.com and would never see those headers, so nothing would stop it using its own cache.)

Or it could use URLs like http://b.com/sneaky.css?unique_random_number so it won't be cached by anything that uses the URL as the cache key.

Or it could set sneaky.css to *not* have the correct hash, and detect whether the browser successfully returns the original style.css (if it uses its SRI-hash-keyed cache because the user had previously visited a.com) or generates an error event (if it tries to load from b.com). That wouldn't require any involvement from the server.

You could try to restrict the SRI-hash cache to be per-origin (i.e. use the domain of the requested resource), but I don't think that would help. The sneaky site could use href="http://a.com/unrelated.css" integrity="[hash of http://a.com/style.css]", and it will either successfully load http://a.com/style.css's content (on a cache hit) or return an error (on a cache miss). If you restrict the cache based on the origin of the requesting page, then you lose the benefit of sharing a cached jquery.js across all sites, so you might as well not bother with the cache.