The hash would be correct. The JS file is the same. The key to the attack is: "t... | Hacker News

Hacker Newsnew | past | comments | ask | show | jobs | submit

		clinta on Oct 1, 2015 \| parent \| context \| favorite \| on: Do not let your CDN betray you: Use Subresource In... The hash would be correct. The JS file is the same. The key to the attack is: "the XSS attack is loading <script src=www.victim.com/evil.js hash=foo>". So victim.com was never hosting evil.js and never intended to serve it. The visitor to victim.com gets it because of an XSS vulnerability. victim.com should be protected because it's content security policy tells the browser not to run scripts from evil.com, but the browser thinks that evil.js came from victim.com, even though victim.com doesn't host evil.js and the browsers cache got evil.js from evil.com.

moe on Oct 1, 2015 [–]

But if the scenario is an attacker who can inject HTML tags, why wouldn't they simply run their script directly via <script>do_evil();</script>?

pauljohncleary on Oct 1, 2015 | [–]

Because a properly configured content security policy will block any inlined js (and external js files on non whitelisted domains)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact