Pourquoi Admin XSS est un problème de sécurité valide

Oops...
Slider with alias none not found.

Par défaut, WordPress permet aux utilisateurs administrateurs et éditeurs d’injecter du JavaScript dans les pages, articles, commentaires et widgets. Ceci est dû au fait que les utilisateurs administrateurs et éditeurs ont la capacité unfiltered_html.

Ici, à WPScan, il est assez fréquent de recevoir des rapports de vulnérabilité via notre formulaire de soumission où le chercheur en sécurité ne savait pas que les utilisateurs administrateurs et éditeurs sont autorisés à injecter du JavaScript.

Mais cela signifie-t-il que toutes les vulnérabilités qui n’affectent que les utilisateurs administrateurs ne sont pas valides ? Non.

Supposons qu’un chercheur en sécurité découvre une vulnérabilité XSS qui n’affecte que les utilisateurs administrateurs. Comme nous l’avons déjà dit, les utilisateurs administrateurs sont autorisés à injecter du JavaScript de toute façon, alors quel est le risque ?

Certains sites Web WordPress peuvent délibérément désactiver la possibilité pour les utilisateurs administrateurs et éditeurs d’injecter du JavaScript, afin d’augmenter la sécurité du site. Cela peut se faire facilement en définissant la constante DISALLOW_UNFILTERED_HTML à true dans le fichier wp-config.php du site. Disons que ce site est très sensible et nécessite une sécurité maximale, comme la Maison Blanche par exemple. Si la vulnérabilité XSS est toujours exploitable, même si le site Web a explicitement désactivé la fonction unfiltered_html, nous considérons alors qu’il s’agit d’une vulnérabilité valide. Un utilisateur administrateur pourrait injecter du JavaScript malveillant dans le navigateur web d’un autre utilisateur administrateur.

Une autre raison pour laquelle les vulnérabilités XSS des administrateurs sont toujours valides est la fonctionnalité WordPress multisite. Lorsque la fonction multisite est activée, les utilisateurs administrateurs perdent la capacité unfiltered_html et celle-ci est donnée aux utilisateurs Super Admin. Dans ce cas, WordPress ne permet plus aux utilisateurs administrateurs d’injecter du JavaScript. Et si un moyen est trouvé pour contourner cela, alors il s’agit d’une vulnérabilité valide.

Le risque de vulnérabilités Cross-Site Scripting (XSS) affectant les utilisateurs administrateurs de WordPress est faible. Dans la plupart des cas, les utilisateurs administrateurs sont autorisés à injecter du JavaScript de toute façon. Pour exploiter les vulnérabilités XSS, une interaction de l’utilisateur est généralement nécessaire, par exemple un utilisateur administrateur connecté qui clique sur un lien malveillant. Et il peut également y avoir des nonces de Cross-Site Request Forgery (CSRF) impliqués.

Mais ce n’est pas parce qu’il est peu probable qu’une vulnérabilité soit exploitée, ou qu’elle soit difficile à exploiter, que nous devons l’ignorer. WordPress alimente une si grande partie du web qu’il est difficile de se tenir au courant des derniers pourcentages de parts de marché. Il doit y avoir des milliers de configurations et d’implémentations différentes, et nous ne pouvons pas supposer, simplement parce qu’une vulnérabilité présente un faible risque, qu’elle n’affectera pas l’un de ces sites de manière plus grave.

Voici quelques exemples de vulnérabilités XSS d’administrateur provenant de notre base de données de vulnérabilités WordPress :

  • WP DoNotTrack <= 0.8.8 – XSS stocké et authentifié (admin+)
  • Async JavaScript < 2.21.06.29 – XSS stocké et authentifié (admin+)

Photo by Olha Ruskykh from Pexels

Similar Posts