2

So my understanding of Service Workers is that once installed they grant you full control over requests to a domain. If an attacker managed to include their service worker in your site, then for anyone who visited that site the service worker could be installed, and then for example proxy all further requests to the site. Removing the service worker's code from your site would not remove it from the browsers which already had installed it. A nefarious service worker could also hide any warnings you added to your site telling your users to clear their browser data - it could serve its own version of your site making any such changes completely ineffective against compromised users' browsers.

If my understanding of service workers is correct, the only way I can think of mitigating such an attack is to send warnings on other domains. For example, if the attack was on a subdomain you could warn on the main domain, but if the attack was on the main domain you might have to send out an alert on Twitter/FB etc. You may also be able to switch domains (or subdomains) away from the attacked domain, but if anyone whose browser bookmarked the compromised domain then they would remain at risk. Is this assessment correct, or are there ways of disabling a service worker that doesn't want to be disabled?

Improve this question
2
  • If there is a suspicion that your server was compromised, you can mitigate the effects of a nefarious installation by changing the API. Or, you can pre-build controls to decommission rogue services through forced updates.
    – postoronnim
    Commented Apr 10, 2020 at 14:09
  • @postoronnim API changes are definitely a good option, though not all sites use them, and an attack like this could still be devastating against a non interactive site
    – curiousdannii
    Commented Apr 10, 2020 at 15:09

1 Answer 1

Reset to default
1

From your link:

Installation is attempted when the downloaded file is found to be new — either different to an existing service worker (byte-wise compared), or the first service worker encountered for this page/site.

and

If there is an existing service worker available, the new version is installed in the background, but not yet activated — at this point it is called the worker in waiting. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more pages to be loaded, the new service worker activates (becoming the active worker). Activation can happen sooner using ServiceWorkerGlobalScope.skipWaiting() and existing pages can be claimed by the active worker using Clients.claim().

It sounds to me that the legitimate site should be able to replace the malicious service worker with a harmless one, once your site is visited again. Of course, you probably can't do anything about it until they come back to your site.

That said, there could be methods that I'm not aware of that allow the malicious service worker to prevent updates.

Improve this answer
1
  • I haven't tried, but I'd expect there's a way to make that URL a random one for each user. But for a less sophisticated attack this may be enough.
    – curiousdannii
    Commented Apr 10, 2020 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .