Re: [w3c/ServiceWorker] Is it possible to serve service workers from CDN/remote origin? (#940)

> Sorry, my comment was rather unhelpful.
> 
> An attacker using an XSS exploit on example.com to register a serviceworker hosted at evil.net by injecting script can just as easily register the serviceworker including a hash in the registration script. Therefore the hash adds no mitigation.
> 
> Perhaps you're not understanding the core XSS problem. It presumes that example.com has an exploit which allows someone to alter the content served by example.com in such a way that arbitrary script is executed. Combined with the ability to register a service worker, this would allow a hacker to cause a service worker to be registered that then intercepts all future loads of example.com content. If the service worker is loaded from evil.com then evil.com now has full control of all content loaded by pages from example.com. The same-origin restriction mitigates this by only allowing scripts hosted at example.com to be registered as a service worker; the worst the XSS exploiter can do is register content under the control of example.com - and badness is possible by abusing existing content within the limits of other mitigations - but in the worst case example.com can replace the content to get back control.
> 
> Once this threat (XSS leading to persistent intercept) and mitigation (same-origin requirement) is understood, it should be clearer why the hash is an insufficient replacement mitigation.

So outside the presumption of an already existing vulnerability, are you thus saying that the hash can provide some meaningful leverage with respect to loading sw files from different domains? @inexorabletash 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/940#issuecomment-441217832