Abusing Service Workers
Last updated
Last updated
Groupe de Sécurité Try Hard
Un travailleur de service est un script exécuté par votre navigateur en arrière-plan, séparé de toute page web, permettant des fonctionnalités qui ne nécessitent pas une page web ou une interaction utilisateur, améliorant ainsi les capacités de traitement hors ligne et en arrière-plan. Des informations détaillées sur les travailleurs de service peuvent être trouvées ici. En exploitant les travailleurs de service dans un domaine web vulnérable, les attaquants peuvent prendre le contrôle des interactions de la victime avec toutes les pages de ce domaine.
Les travailleurs de service existants peuvent être vérifiés dans la section Travailleurs de Service de l'onglet Application dans les Outils de Développement. Une autre méthode consiste à visiter chrome://serviceworker-internals pour une vue plus détaillée.
Les autorisations de notification push impactent directement la capacité d'un travailleur de service à communiquer avec le serveur sans interaction directe de l'utilisateur. Si les autorisations sont refusées, cela limite le potentiel du travailleur de service à poser une menace continue. En revanche, accorder des autorisations augmente les risques de sécurité en permettant la réception et l'exécution d'exploitations potentielles.
Pour exploiter cette vulnérabilité, vous devez trouver :
Un moyen de télécharger des fichiers JS arbitraires sur le serveur et un XSS pour charger le travailleur de service du fichier JS téléchargé
Une requête JSONP vulnérable où vous pouvez manipuler la sortie (avec du code JS arbitraire) et un XSS pour charger le JSONP avec une charge utile qui chargera un travailleur de service malveillant.
Dans l'exemple suivant, je vais présenter un code pour enregistrer un nouveau travailleur de service qui écoutera l'événement fetch
et enverra au serveur des attaquants chaque URL récupérée (c'est le code dont vous auriez besoin de télécharger sur le serveur ou de charger via une réponse JSONP vulnérable):
Et voici le code qui va enregistrer le worker (le code que vous devriez pouvoir exécuter en abusant d'un XSS). Dans ce cas, une requête GET sera envoyée au serveur des attaquants pour notifier si l'enregistrement du service worker a réussi ou non:
En cas d'abus d'un point de terminaison JSONP vulnérable, vous devez placer la valeur à l'intérieur de var sw
. Par exemple:
Il existe un C2 dédié à l'exploitation des Service Workers appelé Shadow Workers qui sera très utile pour abuser de ces vulnérabilités.
La directive de cache de 24 heures limite la durée de vie d'un service worker (SW) malveillant ou compromis à au plus 24 heures après la correction d'une vulnérabilité XSS, en supposant un statut client en ligne. Pour minimiser la vulnérabilité, les opérateurs de site peuvent réduire le Time-To-Live (TTL) du script SW. Les développeurs sont également invités à créer un interrupteur d'arrêt du service worker pour une désactivation rapide.
importScripts
dans un SW via le DOM ClobberingLa fonction importScripts
appelée depuis un Service Worker peut importer un script depuis un domaine différent. Si cette fonction est appelée en utilisant un paramètre qu'un attaquant pourrait modifier, il pourrait importer un script JS depuis son domaine et obtenir une XSS.
Cela contourne même les protections CSP.
Exemple de code vulnérable :
index.html
sw.js
Pour plus d'informations sur ce qu'est le DOM Clobbering, consultez :
Dom ClobberingSi l'URL/domaine utilisé par le SW pour appeler importScripts
est à l'intérieur d'un élément HTML, il est possible de le modifier via le DOM Clobbering pour que le SW charge un script depuis votre propre domaine.
Pour un exemple, consultez le lien de référence.
Groupe de sécurité Try Hard