Hacker News Reader

Comment by icebraining | Hacker News Reader

In this case, if a company dies and a malicious actor gets the domain, there's not much they can do besides tell the browser to load those assets - but they could probably just take a copy of the original site and serve a copy of those assets themselves.

The attack might work the other way around: the attacker buys a bunch of domain names, serves "sleeper" malicious JS files with this on common paths (say, the paths used by Wordpress and other common CMSs), then releases the domain. When the new owner installs a CMS and start serving their site, the browser loads the malicious JS instead, which is now running under the new site's Origin (security context).

View on HN

But to make this attack work, browsers would have to visit this site before the new owner takes it over, in order to receive and cache the malicious JS. And if you can make people receive malicious JS, you've already got your attack vector - immutable caching isn't needed.

if you can make people receive malicious JS, you've already got your attack vector

No, because a malicious JS file by itself can't do much. The attack vector is the malicious JS running on the new site, with permissions to steal session cookies and interact with the application. That's why caching without verification is important: to make sure the browser uses the cached malicious JS instead of fetching the new one.

That's an interesting attack vector, in the section 3 of the RFC they recommend to ignore the directive unless it's a secure connection which would mitigate that kind of problems.

Another solution would be to use an unpredictable versioning scheme so the attacker can't anticipate the name of the resources.

The attacker who buys a bunch of domains and legitimately owns them for a period of time wouldn't have any issue getting SSL certificates for them.

Correct, but, even if not explicitly said, the cached entries should be associated to the certificate's fingerprint and immediately discarded once the certificate expires or is changed.

Certificates often change for legitimate reasons, e.g. Let's Encrypt certificates which must be changed every 3 months.

That would be ok.

Isn't this also true for long cache control durations as well?

Yes, although an immutable guarantee makes it more likely that the browser won't check for a new version.

Reply on news.ycombinator.com