Récemment une vulnérabilité a été découverte ce qui pourrait permettre aux responsables de bloquer les listes de filtres pour les extensions de navigateur Adblock Plus, AdBlock et uBlocker pour créer des filtres qui injectent des scripts distants dans les sites Web.
Avec une base d'utilisateurs qui a franchi la barre des 10 millions, si des scripts malveillants étaient injectés dans les bloqueurs de publicités, cela aurait un impact considérable Parce qu'ils pourraient effectuer des activités indésirables, telles que le vol de cookies, des informations de connexion, des redirections de pages ou d'autres comportements indésirables.
Pour ceux qui ne sont pas familiers avec les bloqueurs de publicités, ils utilisent essentiellement des listes d'URL liés aux publicités et comportements malveillants.
Habituellement, Ils sont dirigés par une petite équipe de personnes ou même une seule personne.
Lorsque ces listes sont chargées avec une extension de blocage des publicités telle qu'Adblock Plus, cette extension empêchera le navigateur de se connecter aux URL mises dans la liste et empêchera ainsi la connexion à des publicités ou scripts malveillants.
L'option de filtre $ rewrite est à l'origine du problème
Quand Adblock Plus 3.2 lancé en 2018, il a ajouté une nouvelle option de liste de filtres, appelée $ rewrite.
Cette option autorisé à un responsable de liste remplacer une requête Web qui correspond à une expression régulière en particulier avec une autre URL.
Hubert Figuière, qui a introduit cette fonction, a expliqué que:
«Depuis Adblock Plus 3.2 pour Chrome, Firefox et Opera (et les versions de développement de 3.1.0.2053), une nouvelle option de filtre $ rewrite permet de réécrire l'URL d'une ressource au lieu de la bloquer.
Lorsqu'Adblock Plus attribue une URL de demande à un filtre avec l'option $ rewrite, il transforme l'URL en fonction de la règle fournie et indique au navigateur de charger la ressource en même temps.
La syntaxe de la règle $ rewrite spécifie une chaîne qui sert de modèle pour la nouvelle URL.
$ n est remplacé par la n-ième sous-correspondance de l'expression régulière du filtre. Il s'agit de la même syntaxe que la fonction JavaScript String.prototype.replace ().
Si l'URL résultante est relative (c'est-à-dire que vous n'avez pas d'hôte), l'origine de la requête d'origine sera utilisée comme base. Dans les deux cas, si la nouvelle URL ne partage pas l'origine, la réécriture sera considérée comme infructueuse et la demande initiale sera acceptée.
De plus, les filtres $ rewrite sont ignorés pour les requêtes SCRIPT, SUBDOCUMENT, OBJECT et OBJECT_SUBREQUEST pour des raisons de sécurité. Cette option est pratique pour modifier ou supprimer les paramètres de requête ».
Le seul inconvénient est que la chaîne de remplacement doit être une URL relative, ce qui signifie qu'elle ne contient pas de nom d'hôte et, lorsqu'elle est réécrite, elle doit appartenir au même domaine d'origine que la demande.
L'exécution du code se fait même sur google maps
Un chercheur en sécurité a expliqué Québec:
Dans certaines conditions, il est possible qu'un mainteneur de filtre malveillant non autorisé crée une règle qui injecte un script distant dans un site particulier.
Pour faire ceci, cherchez simplement un site qui charge des scripts depuis n'importe quel domaine contenant une redirection ouverte et utilisez XMLHttpRequest ou Fetch pour télécharger les scripts à exécuter.
Ce n'était pas trop difficile à trouver parce que pour faire ça seul utilisez simplement Google Maps comme preuve de concept.
Le chercheur a expliqué que les critères suivants doivent être remplis afin qu'un service web puisse être exploité avec cette méthode:
- La page doit charger une chaîne JS à l'aide de XMLHttpRequest ou Fetch et exécuter le code de retour.
- La page ne doit pas restreindre les sources à partir desquelles elle peut être récupérée à l'aide des consignes de politique de sécurité du contenu, ni valider l'URL de la demande finale avant d'exécuter le code téléchargé.
- La source du code récupéré doit avoir une redirection côté serveur ouverte ou un contenu utilisateur arbitraire de l'hôte.
L'utilisation de XMLHttpRequest ou Fetch pour télécharger des scripts et ouvrir la redirection sont les deux clés du problème.
Pour atténuer ce problème, il est recommandé que les sites Web utilisent l'en-tête de stratégie de sécurité du contenu et l'option connect-src pour spécifier une liste blanche de sites à partir desquels les scripts peuvent être chargés.