Les Service Workers sont des scripts qui s'exécutent en arrière-plan, indépendamment des pages Web, et qui permettent d'activer des fonctionnalités telles que le mode hors ligne et les notifications push. Bien que puissants, ils nécessitent une attention particulière en matière de sécurité, car ils peuvent intercepter et modifier les requêtes réseau. Ils doivent être servis via HTTPS et respecter les restrictions de même origine.
Un service worker est un fichier JavaScript que le navigateur enregistre pour s'exécuter en arrière-plan, découplé de toute page individuelle et même lorsqu'aucun onglet n'est ouvert. Il se place comme un proxy réseau programmable entre le site et le réseau : via l'événement fetch, il peut intercepter les requêtes sortantes, y répondre depuis un cache, les réécrire ou les transmettre. C'est ce qui alimente les expériences hors ligne, la synchronisation en arrière-plan et les notifications push dans les progressive web apps. Les service workers sont pilotés par événements et n'ont pas accès au DOM ; ils communiquent avec les pages par messagerie. Leur enregistrement est strictement contraint : ils doivent être diffusés en HTTPS, respecter la same-origin policy, et leur portée est limitée au chemin depuis lequel ils sont diffusés.
Parce qu'un service worker peut intercepter et réécrire chaque requête au sein de sa portée et qu'il persiste d'une session à l'autre, il occupe une position exceptionnellement puissante et durable sur le client. Si un attaquant parvient à enregistrer un worker malveillant, par exemple via un point de téléversement qui sert du JavaScript contrôlé par l'attaquant à une portée large, ou en exploitant une faille d'injection de script existante, il obtient un point d'ancrage man-in-the-browser persistant qui survit aux rechargements de page et peut manipuler silencieusement le trafic, servir de faux contenus ou récolter des données longtemps après la fermeture du point d'entrée d'origine. Les exigences HTTPS et de même origine existent précisément parce que cette capacité serait catastrophique si un attaquant réseau ou une origine étrangère pouvait en implanter un.
Verrouillez les emplacements depuis lesquels des scripts peuvent être servis afin qu'un attaquant ne puisse pas héberger un worker à une portée utile : assainissez et fixez le content-type des téléversements utilisateurs, évitez de servir du JavaScript contrôlé par l'utilisateur depuis votre origine, et contraignez la portée d'enregistrement avec l'en-tête Service-Worker-Allowed. Une Content Security Policy avec worker-src restreint quels scripts peuvent devenir des workers, et la Subresource Integrity ainsi que la revue des chaînes de build protègent le fichier de worker légitime lui-même. cside complète cela en servant de proxy et en analysant les scripts third-party qu'une page charge, et en bloquant les comportements malveillants en temps réel ; la trace forensique du code exécuté qui en résulte aide les enquêteurs à reconstituer comment un worker véreux ou un script injecté a atteint le navigateur.
Un service worker n'a aucun accès direct au DOM et ne peut pas toucher à document.cookie, puisqu'il s'exécute hors du thread principal. En revanche, il peut intercepter les requêtes réseau au sein de sa portée et inspecter ou modifier leurs en-têtes et leurs corps, ce qui lui confère une influence substantielle sur les données circulant vers et depuis la page.
Un service worker peut intercepter et réécrire tout le trafic réseau de sa portée, donc autoriser son installation via du HTTP en clair permettrait à un attaquant de type man-in-the-middle réseau d'implanter un proxy persistant dans le navigateur de la victime. Exiger le HTTPS garantit que le script du worker est authentifié et non altéré avant que le navigateur lui accorde ce pouvoir.
We answer client-side security questions every day. Bring yours.