Tuesday, September 5. 2017
Abandoned Domain Takeover as a Web Security Risk
Comments
Display comments as
(Linear | Threaded)
Yeah, this is a huge security issue. Thanks for doing your part to get the word out!
There is a solution you didn't mention that allows you to keep using 3rd party hosts safely.
It's known as Subresource Integrity (SRI). It's simple: just add a hash attribute to every script and stylesheet element so that they will only load the file if the hash matches a known safe hash. This doesn't work well for dynamically generated or frequently updated scripts, but it's just fine for loading a specific version of Jquery from an external CDN.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Additionally, a strict Content Security Policy (CSP) could potentially limit some of the more dangerous effects of a compromised script. Unfortunately it won't stop a page from becoming unusable or getting its background turned pink. Strong CSPs are difficult to implement on existing websites, but not too bad if you're starting from scratch.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
There is a solution you didn't mention that allows you to keep using 3rd party hosts safely.
It's known as Subresource Integrity (SRI). It's simple: just add a hash attribute to every script and stylesheet element so that they will only load the file if the hash matches a known safe hash. This doesn't work well for dynamically generated or frequently updated scripts, but it's just fine for loading a specific version of Jquery from an external CDN.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Additionally, a strict Content Security Policy (CSP) could potentially limit some of the more dangerous effects of a compromised script. Unfortunately it won't stop a page from becoming unusable or getting its background turned pink. Strong CSPs are difficult to implement on existing websites, but not too bad if you're starting from scratch.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
I'm aware of SRI. However if you include a static resource from a thirdparty domain you can also just store it locally. (Yeah, I know, CDN caching etc., but I doubt that makes much of a difference in most cases.)
I don't see how CSP helps in this particular attack scenario. I generally advocate the use of CSP, but if you whitelist a domain in CSP then it doesn't help you against that domain going rogue.
I don't see how CSP helps in this particular attack scenario. I generally advocate the use of CSP, but if you whitelist a domain in CSP then it doesn't help you against that domain going rogue.
I had guessed someone like you would be familiar with it. And yeah, those are the only good reasons not to keep a local copy.
The CSP part made more sense to me when I wrote it. I must have been thinking of blocking stuff like unsafe-eval... but honestly what good is that when your whole page is already compromised?
The CSP part made more sense to me when I wrote it. I must have been thinking of blocking stuff like unsafe-eval... but honestly what good is that when your whole page is already compromised?
A few days ago I figured out that several blogs operated by T-Mobile Austria had a Git repository exposed which included their wordpress configuration file. Due to the fact that a phpMyAdmin installation was also accessible this would have allowed me to c
Tracked: Apr 11, 13:42