> Distributing malicious JavaScript content
The authors consider three ways to do this: – directly compromising (or colluding with) web servers hosting JS code; injecting malicious JavaScript when JS libraries are accessed over unprotected connections (HTTP instead of HTTPS); and redirecting requests for JS content via compromised name resolution.
Importantly, the first and third can be mitigated by subresource integrity (SRI) in modern browsers. If you don't control the host/CDN serving your static JS, that's how you protect against these attacks.
(The second, of course, is mitigated by regular old HTTPS.)
In this study, the JS is on a host separate from the site itself. Malicious JS from the compromised host will not match the SRI signature embedded in the HTML, and will be rejected.
If the main HTML web server is compromised, there's nothing you can do: a compromised web server can send whatever <SCRIPT> tag it wants.
CloudFlare has certainly and quite quickly become a major player in the internet game. For what it's worth, I've spent hours talking to Matthew Prince and while I'm sure he may rub some the wrong way he's undoubtedly a really good human. I'm thankful he and Michelle Zatlyn (an equally awesome and talented person) are steering that ship given the power they hold.
Importantly, the first and third can be mitigated by subresource integrity (SRI) in modern browsers. If you don't control the host/CDN serving your static JS, that's how you protect against these attacks.
(The second, of course, is mitigated by regular old HTTPS.)
reply