Service Workers são scripts que rodam em segundo plano, separados das páginas web, viabilizando recursos como funcionamento offline e notificações push. Apesar de poderosos, exigem atenção cuidadosa à segurança, pois podem interceptar e modificar requisições de rede. Eles precisam ser servidos por HTTPS e seguir as restrições de mesma origem.
Um service worker é um arquivo JavaScript que o navegador registra para rodar em segundo plano, desacoplado de qualquer página específica e mesmo quando nenhuma aba está aberta. Ele fica como um proxy de rede programável entre o site e a rede: por meio do evento fetch, pode interceptar requisições de saída, respondê-las a partir de um cache, reescrevê-las ou repassá-las. É isso que viabiliza experiências offline, sincronização em segundo plano e notificações push em progressive web apps. Os service workers são orientados a eventos e não têm acesso ao DOM; eles se comunicam com as páginas por meio de mensagens. O registro é fortemente restrito, eles precisam ser servidos por HTTPS, obedecer à same-origin policy e seu escopo é limitado ao caminho a partir do qual são servidos.
Como um service worker pode interceptar e reescrever cada requisição dentro do seu escopo e persiste entre sessões, ele ocupa uma posição incomumente poderosa e duradoura no cliente. Se um invasor conseguir registrar um worker malicioso, por exemplo por meio de um endpoint de upload que serve JavaScript controlado pelo invasor em um escopo amplo, ou explorando uma falha existente de injeção de scripts, ele ganha uma posição persistente de man-in-the-browser que sobrevive a recarregamentos de página e pode manipular tráfego silenciosamente, servir conteúdo falso ou coletar dados muito depois de o ponto de entrada original ter sido fechado. Os requisitos de HTTPS e same-origin existem precisamente porque essa capacidade seria catastrófica se um invasor de rede ou uma origem externa pudesse plantar um.
Restrinja de onde os scripts podem ser servidos para que um invasor não consiga hospedar um worker em um escopo útil: higienize e defina o content-type dos uploads de usuários, evite servir JavaScript controlado pelo usuário a partir da sua origem e limite o escopo de registro com o cabeçalho Service-Worker-Allowed. Uma Content Security Policy com worker-src restringe quais scripts podem se tornar workers, e a Subresource Integrity, somada à revisão dos pipelines de build, protege o próprio arquivo legítimo do worker. A cside complementa isso proxiando e analisando os scripts third-party que uma página carrega e bloqueando comportamento malicioso em tempo real; o registro forense resultante do código executado ajuda os investigadores a reconstruir como um worker desonesto ou um script injetado chegou ao navegador.
Um service worker não tem acesso direto ao DOM e não pode tocar em document.cookie, já que roda fora da thread principal. No entanto, ele pode interceptar requisições de rede dentro do seu escopo e inspecionar ou modificar seus cabeçalhos e corpos, o que lhe dá influência substancial sobre os dados que fluem de e para a página.
Um service worker pode interceptar e reescrever todo o tráfego de rede em seu escopo, então permitir que um seja instalado por HTTP em texto simples deixaria um man-in-the-middle de rede plantar um proxy persistente no navegador da vítima. Exigir HTTPS garante que o script do worker seja autenticado e não adulterado antes de o navegador lhe conceder esse poder.
We answer client-side security questions every day. Bring yours.