Do not let your CDN betray you: Use Subresource Integrity

Generating two files where their hashes collide is extremely difficult. Generating two files where their hashes collide at the same size is near impossible, even after you break the hash function itself (e.g. with MD5 it requires much more compute power to generate two files with matching hashes and sizes than just hashes alone, since you're effectively looking for a subset of all collisions).

I made a site where I 'guessed' if a user was an employee of a certain company by embedding an <img> from an employee portal (from the login screen) and timing how long it took for onLoad to trigger. Times under a certain threshold indicated that the image was probably cached and they work there.

Of course, once you load it once it's cached, so you need to persist the first result... but you get the drift.

Sharing resources across pages based on has values would render this restriction moot.

From http://www.w3.org/TR/resource-timing/:

"Statistical fingerprinting is a privacy concern where a malicious web site may determine whether a user has visited a third-party web site by measuring the timing of cache hits and misses of resources in the third-party web site. Though the PerformanceResourceTiming interface gives timing information for resources in a document, the cross-origin restrictions prevent making this privacy concern any worse than it is today using the load event on resources to measure timing to determine cache hits and misses."

There's a warehouse 'owner' internal to the browser (and not exposed to pages/extension), who 'remembers' the resources the browser has, and the times it took to access them (for commonly-accessed resources). When a page requests the cached resource, the owner 'returns' the resource with a delay of whatever the original access time was, fudged around by some noise.

A weakness of this would be that websites would be able to 'communicate' with each other by engineering response times to your browser, and then checking how long it takes your browser to access that. But this is a different scenario than random websites trying to figure out where else you've been: here the pages need to be in collusion with each other.

The servers might try to use fancy algorithms to try to figure out if you're using cached versions by hitting different distributed servers and figuring out if the resource load time is an outlier. But that's prone to a lot of noise and other issues, and lesser of an issue than the original concern. Right?

This obviously won't help with page load speeds, but will help network load for bot users and servers. One possible issue might be: if you've been in a slow connection previously, all your connections will seem slow even after you are in a faster connection. For that, you can just purge the cache and force the browser to reload the resources.

Edited for formatting.

A site operator would only opt in to the behavior for assets that are not unique to the site.

A second idea would be to wait until several unique domains had requested the asset before turning on the behavior for that asset. (By unique domain I specifically mean the part of the domain that's written in black text in the URL bar, excluding subdomains that are in gray.)

These are two easiest-to-implement solutions I can think of.

What would the attacker here be doing, and how? I read the piece on your site, and it's not clear to me what the attacker would be updating, and what effect it would have. Can you explain?

> Content injection (XSS)

If we assume XSS, an attacker could simply inject whatever they want. The cache isn't needed. This still wouldn't poison any legitimate cache keys.

> The client still has to find out if the server really hosts this file.

So use (URL, hash) as the key in the permanent cache. This removes most of the bandwidth, and using a CDN allows for one GET per file across many sites.

So what exactly is the attack? I'm really not seeing how someone could attack a permanent cache without first breaking the hashing functions that we already have to trust.

edit: after reading https://news.ycombinator.com/item?id=10311555

This would work in the cases where we allow XSS (which is already a compromised scenario). Simply adding the URL (or maybe even just the hostname) prevents this entirely, and we still get almost all of the benefits for local resources, and we get all of the benefits when using a CDN.

edit2:

There are two issues being discussed. 1) Is the file we loaded form a (possibly 3rd party) site correct? 2) Did we ask for the correct file(s).

Cache poisoning is when you can fool #1, while XSS attacks manipulate #2.

   cache = {
	b0af301e782bf5e2a8ccce919b6ca3b70aa771db: 
        {domains: ['evil.com','airbnb.com'], content: '...'},
	35d778783c4155c20360d269c9dd000fdcd39548: 
        {domains: ['javajosh.com'], content:'...'}
   }

(Something I personally would like would be for for orgs like EFF.org to post known-good hashes, so I can always add the EFF hashes to my site's CSP whitelist, and have a warm-and-fuzzy feeling.)

I think this would also allow the server to "pre-validate" with HTTP2 push.

1. Add an If-Hash-Mismatch header so you don't need to transfer the body

2. Add a list of hashes to accept to the content security policy headers

3. Add a list of public keys to accept to the content security policy, and allow the content if it's signed by one of those (this requires some standard way of signing things, maybe PGP/MIME or a dedicated HTTP header)

4. Only allow this from <script> and <style> tags that are in the <head>, or that are at "end" of <body> (meaning there are no tags other than <script> or <style> afterwards), or resources referenced from CSS and JavaScript files loaded that way.

EDIT: 5. Add an ECC public key (Curve25519?) to the content security policy, and accept hashes where an extra attribute is specified providing an inline signature of the hash with the key

The idea of the last one is that XSS would usually happen in in the middle of the body and not in the head or footer.

That said, you can XSS with inline script, so it seems this only mitigates XSS vulnerability with length limitations on the payload (EDIT: nope, CSP blocks inline script).

Source: https://w3c.github.io/webappsec/specs/subresourceintegrity/#...

I suspect this is going to become a turbo AdBlock. If the original page doesn't sign the content, block it.

Fair enough, that's some information leakage, but it's certainly not easy to exploit. Normal cross-origin limitations still apply, so you'd need to get creative to even get the information in the first place, and if you can, it's not clear what this adds over a timing attack.

I'm still a little skeptical such a heavy handed restriction is necessary to maintain the current level of security; but then again - why take the risk?

Hopefully, subresource integrity schemes will eventually allow browsers to fetch from local cache based on the checksum of the file contents, rather than the URI from which the resource is served. :)

It raises the bar though from blind injection, which I think is quite good.

It would add overhead to verify hashes in the manner that you have mentioned but I think it's worth it.

If average page size is 500 Kb and jquery size is 30 Kb gzipped you do not save much by hosting is on a CDN. What you get is more DNS requests, more downtime when that server fails or stalls and give out data about your users.

I think it is easier just to host everything on your own server.