Nice article! I just finished a small research on the same topic, so good to read yours aswell! I'd like to mention another solution: use strict CSP headers. That way you can block requests which are not allowed. Nice article, keep up te work!
Thanks! I didn't consider CSP while writing this, so it seems interesting.
Indeed the best way is to self-host every asset, and then use CSP to block any additional calls that you did not expect. Otherwise even if one of the CSS files is on a server they can still use this vulnerability.
I will update the article based on your suggestion:)
Using strict CSP you can block the background-image requests, which would be the malicious domain/api of the attacker. Using strict csp directives you can block these requests, that's how we're doing it at my current job
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article! I just finished a small research on the same topic, so good to read yours aswell! I'd like to mention another solution: use strict CSP headers. That way you can block requests which are not allowed. Nice article, keep up te work!
Thanks! I didn't consider CSP while writing this, so it seems interesting.
Indeed the best way is to self-host every asset, and then use CSP to block any additional calls that you did not expect. Otherwise even if one of the CSS files is on a server they can still use this vulnerability.
I will update the article based on your suggestion:)
CSP is useful, but I don't think it is for this case as the initial resource and hack are loaded from the same domain.
Wouldn't it be more useful to add an integrity check to make sure the file is not updated? Do link nodes support the integrity attribute?
Using strict CSP you can block the background-image requests, which would be the malicious domain/api of the attacker. Using strict csp directives you can block these requests, that's how we're doing it at my current job