CDNs are used to distribute e.g. the jquery for most websites out there. This makes the browser able to cache it and thus load it faster.
This document talks about practical attacks by or against CDNs and potential solutions to them.
Browsers cache data, but not metadata. Every time you load a website, it's still gonna send a request for the metadata.
There's some limited caching of metadata, but it's so limited as to be practically useless.
The browser also sends some metadata of its own:
- The user agent
- The IP address (indirectly through a TCP connection)
- The referrer
The flawed caching mechanism on its own is not a big deal - an active attacker would be able to link IPs and referrers for new requests, but would quickly be found out.
On the other hand, a much more serious attack involves logging. Most CDNs log, including IP addresses and referrer headers. If the attacker is in, it's much easier for them to just grab all existing logs they can find than to log all new requests.
CDNs can modify the served files at any time. While on one hand this can be good, e.g. newer minification techniques could reduce the size of JS files, this also means they could start serving malicious files at any time. They can also make files unavailable at any time, breaking existing websites.
CDNs, like any other service, can suffer from DoS attacks, close down, or delete some older files.
Modern protocols like DNSSEC make some DoS attacks significantly harder to pull off, but not entirely out of question.
Currently, the following mitigations are available:
- Subresource tags can specify a hash, this is called "subresource integrity". This protects the user from malicious scripts, but not from denial-of-service.
- Some tags can specify a referrer policy. This can be used for cross-domain tracking protection.
Potential future mitigations include:
- Allow
<script>tags to specify a referrer policy. - Allow longer-term metadata caching. This is mainly a performance/efficiency benefit as the browser wouldn't have to make as
many HTTP(S) requests, but this also cuts down on the number of times metadata is sent to the CDN.
- Actually, subresource caching should just be straight-up overridable by the webpage.
- Magnetized resources could permanently solve DoS and availability problems.
One way some of these might look like:
<script src="cdn" integrity="sha256-some_base64_here" referrerpolicy="no-referrer" type="text/javascript"></script>
However, most developers will just copy the src, and not pay attention to the hash or referrer options.
Another solution is to use magnetized transfers as a CDN. This still solves the mutability, tracking, and caching problems, while also solving availability problems and providing much better locality - in many households, files could be fetched straight from LAN.
CDNs are broken by design. There are some mitigations, but we aren't there yet.
Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Referrer Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
TODO: fill this in
Copyright (C) Soni L. 2018
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
