3 ms·
> Distributing malicious JavaScript content The authors consider three ways to do this: – directly compromising (or colluding with) web servers hosting JS code;
by krallja 9y ago
> 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.)
- therobot 9y agoI agree for the third, but how sri will protect you from the first attack?
- krallja 9y agoIn 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.
- therobot 9y agodirectly compromising in my understanding tells me that the server is compromised. The server suddenly "decides" to distribute malicious JS.