Pourquoi cette vulnérabilité existe-t-elle ? CVE-WPFormulaires)

Ces derniers jours, j'ai remarqué que la vulnérabilité CVE-2024-11205 (CVSS 8.5) dans le plugin Wordpress WPForms attirait beaucoup d'attention. Principalement pour 3 raisons :

• WPForms est un plugin largement utilisé, avec plus de 6 millions d'installations actives (sites l'utilisant)
• Il s'agit d'une vulnérabilité de haute criticité
• C'est bizarrement simple à comprendre

Le message original de Wordfence a déjà fait un excellent travail en expliquant la vulnérabilité et ses conséquences. Par conséquent, mon objectif ici est différent : théoriser comment une vulnérabilité aussi étrangement simple est restée ouverte pendant plus d'un an dans l'un des plugins Wordpress les plus utilisés.

Vulnérabilité

Rappel des informations du message d'origine. Le plugin utilise les fonctions ajax_single_payment_refund() et ajax_single_payment_cancel() pour gérer les actions de paiement Stripe. Cependant, il n'y a aucune validation si l'utilisateur connecté est autorisé à effectuer de telles actions ⚰️. Pour couronner le tout, les fonctionnalités ont été « protégées » par la méthode wpforms_is_admin_ajax, qui ne vérifie tout simplement pas si l'utilisateur est un administrateur, comme certains pourraient le penser.

Réparer

En commençant par l'atténuation des vulnérabilités, le correctif officiel consiste à mettre à jour vers la version 1.9.2.2. Dans cette version du code, la validation d'autorisation a été ajoutée aux deux fonctionnalités, ajax_single_payment_refund et ajax_single_payment_cancel. Cependant, wpforms_is_admin_ajax a été conservé tel quel ?.

Quand la vulnérabilité est-elle apparue ?

La première version vulnérable est WPForms 1.8.4 publiée le 28 novembre 2023. La version a introduit de « nouveaux outils de paiement Stripe », comprenant, entre autres, « Tableau de bord Stripe synchronisé » et « Logique pour les paiements récurrents ».

En tant que changements, la mise à jour a apporté l'ajout de 15 nouveaux fichiers, la suppression de 64 fichiers et l'édition de 425 fichiers. Cela ressemble à une excellente version à réviser manuellement ☠️.

Pourquoi la vulnérabilité existe-t-elle ?

Les outils de sécurité automatisés peuvent-ils détecter ?

Pour répondre à cette question, j'ai testé SAST Semgrep (que j'aime beaucoup utiliser) et Gepeto (alias ChatGPT).

Semgrep

J'ai exécuté un semgrep. dans l'ensemble du projet et il n'a pas pu détecter la vulnérabilité ?.

Le résultat est comme prévu. Officiellement, les vulnérabilités liées aux échecs d’autorisation sont considérées comme des vulnérabilités de logique métier. Ce qui signifie qu’ils sont difficilement détectés par les outils automatisés.

L'Énumération des faiblesses communes L'autorisation manquante CWE-862 semble être d'accord.

Geppetto

J'ai demandé à ChatGPT s'il pouvait identifier des problèmes dans le code précédent. Je lui ai seulement envoyé les méthodes ajax_single_payment_refund et wpforms_is_admin_ajax (parce que je ne veux pas utiliser mon ChatGPT gratuit pour la journée ?).

Et incroyablement, il a réussi à identifier la vulnérabilité et à signaler la solution (qui était très similaire au vrai correctif ?), parmi d'autres « vulnérabilités possibles » dans ce code, comme No Rate Limiting ou Logging.

« ahh, mais tu as exécuté SAST sur tout le projet, tout en dirigeant l'IA », c'est vraiment la vie comme ça ? ?‍♂️

Pourquoi la vulnérabilité existe-t-elle ?

Comme nous l'avons vu, les outils de sécurité traditionnels peuvent difficilement détecter les vulnérabilités d'autorisation.

Selon l'autorisation manquante CWE-862, cette vulnérabilité peut être détectée à l'aide d'une analyse manuelle, telle que la révision du code, le pentest et la modélisation des menaces. Et l'efficacité est considérée comme « modérée » uniquement ?.

D'autres documents qui parlent des vulnérabilités d'autorisation renforcent le fait qu'il s'agit d'une classe de vulnérabilités compliquées à gérer et courantes dans le monde réel, comme OWASP Top 10 API Security 2019 et 2023 qui a des vulnérabilités d'autorisation comme première et troisième. poste.

Un autre point est que la méthode précédemment utilisée comme validation (wpforms_is_admin_ajax) a une très mauvaise réputation, conçue pour confondre les développeurs et les réviseurs de code, car cette fonction ne vérifie pas si l'utilisateur connecté est administrateur.

Donc, ma théorie est que cette vulnérabilité existe parce que 1) sans analyse manuelle, elle est presque impossible à détecter ; 2) la méthode wpforms_is_admin_ajax confondrait de nombreux réviseurs analysant le code.

J'espère apporter d'autres analyses comme celle-ci dans le futur. Si vous avez aimé, partagez la publication avec tante et grand-mère. Des doutes ? Je suis toujours sur Bluesky, Threads et Twitter.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!