HTML Subresource Integrity

Posted Jul 4, 2016 16:30 UTC (Mon) by oever (guest, #987)
In reply to: HTML Subresource Integrity by flussence
Parent article: HTML Subresource Integrity

I've just tested RSI with Chromium 51 and Firefox 47. Both browsers check RSI on the <script> and <link> and refuse to use the linked CSS or JavaScript when the checksum is not correct. This is in agreement with what is written in the parent article.

What I've not checked, is whether the browser will use the checksum to retrieve the file from the cache instead of loading it from a 3rd party browser.

This is an quick way to get a base64 encoded checksum for use in HTML with SRI:

cat file | openssl dgst -binary -sha256 | base64

to post comments

HTML Subresource Integrity

Posted Jul 4, 2016 19:35 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (8 responses)

> What I've not checked, is whether the browser will use the checksum to retrieve the file from the cache instead of loading it from a 3rd party browser.

Hopefully the URL also has to match. Some interesting XSS-like attacks come to mind otherwise.

HTML Subresource Integrity

Posted Jul 4, 2016 19:47 UTC (Mon) by oever (guest, #987) [Link] (7 responses)

I'm not a security researcher and lack the creativity needed to see a possible attack. Do you have an example?

If the browser uses the hash as an identifier a lot of network traffic can be avoided.

Git works by using the hash, sha1 even, for identification of files. I think it would be safe to use for the entire web too.

HTML Subresource Integrity

Posted Jul 4, 2016 20:32 UTC (Mon) by dtlin (subscriber, #36537) [Link] (6 responses)

One obvious one:

Perhaps you visited http://a.com, and the browser fetches a cachable resource http://a.com/style.css with checksum 1234. Or not.

Now you visit http://b.com, which says

<link rel="stylesheet" href="http://b.com/sneaky.css" integrity="1234">

— while it 404's that path (or anything that doesn't get cached).

If the browser were to skip fetching http://b.com/sneaky.css because it already had content with hash 1234 in cache, then b.com would quite reliably be able to determine whether the user had visited a.com just by looking to see which of their visitors doesn't make a request to http://b.com/sneaky.css. (It's already possible to be tricksy by measuring timing to load things in Javascript, but that's kind of a problem too.)

HTML Subresource Integrity

Posted Jul 4, 2016 21:27 UTC (Mon) by oever (guest, #987) [Link]

You're right. That's a deal breaker. The URL will have to be the same too.

HTML Subresource Integrity

Posted Jul 5, 2016 8:35 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

How can b.com determine that? All it means is there a cache _somewhere_ between the user and b.com. That cache could be tied to the user (i.e. in the user's browser profile), or it could be shared amongst many, many people (some large-network level transparent cache).

HTML Subresource Integrity

Posted Jul 5, 2016 11:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Cache control headers can prevent caching by most software. Plus, the cached file could ping back (e.g., CSS font stuff or an explicit XHR) and then you know at least that the file was cached before and not having a GET query paired with it means that it was visited before. I imagine network level cause to be rare enough as to not matter much.

HTML Subresource Integrity

Posted Jul 6, 2016 16:26 UTC (Wed) by zlynx (guest, #2285) [Link]

It may be somewhat rare but there are still many places that force caches to ignore cache-control because the benefits exceed the annoying but rare need to shift-reload in the browser.

Satellite links, mesh networks, or exceedingly slow radio links are all examples.

Sites that try to force the 304 If-Modified check just for user stats are, in my opinion, evil and stupid, and forcing it to be treated as Expires is almost always a good thing.

HTML Subresource Integrity

Posted Jul 5, 2016 12:18 UTC (Tue) by excors (subscriber, #95769) [Link] (1 responses)

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.

HTML Subresource Integrity

Posted Jul 5, 2016 12:46 UTC (Tue) by paulj (subscriber, #341) [Link]

Interesting. Cheers.