Titre : Vulnérabilité corrigée dans phpMyAdmin

Vulnérabilité de type : Cross-Site Scripting (XSS)

Numéro CVE : CVE-2022-23808

Risque : important

Impact : important

Systèmes affectés

• Les versions phpMyAdmin de la branche 5.1 antérieures à 5.1.2 sont concernées.

Bilan de la vulnérabilité

Plusieurs vulnérabilités ont été corrigées dans l’interface web de gestion des systèmes bases
de données MySQL phpMyAdmin. L'exploitation d’une de ces vulnérabilités pourrait
permettre à un attaquant d’injecter du contenu dans une page ou d’avoir accès à des données
confidentielles.

Solution :
Veuillez-vous référant aux bulletins de sécurité suivants pour mettre à jour
phpMyAdmin :

https://www.phpmyadmin.net/security/PMASA-2022-2/
Lien vers le(s) commit(s) de code source (par exemple, Git, SVN) où la vulnérabilité a été
corrigée .
https://github.com/phpmyadmin/phpmyadmin/commit/5118acce1dfcdb09cbc0f73927bf51c46
feeaf38
https://github.com/phpmyadmin/phpmyadmin/commit/44eb12f15a562718bbe54c9a16af91cee
a335d59

Qu’est-ce que le Cross-Site Scripting (XSS)

Les failles de type XSS (Cross Site Scripting) surviennent lorsqu’une application récupère des
données non fiables et les envoie à un navigateur Web sans aucune validation (vérification des
données saisies dans les champs, échappement des caractères suspects). À la différence des
injections SQL, les failles XSS se caractérisent par l’injection de code HTML ou JavaScript
dans des variables mal protégées.

XSS permet à un attaquant d’exécuter des scripts dans le navigateur Web de la victime, ce qui
peut entraîner des détournements de sessions ou des défacements de sites Web. L’attaquant
peut par exemple rediriger l’utilisateur vers des sites Web malveillants. Il existe cependant
deux catégories de failles XSS :
 1 – Les failles XSS réfléchissantes (reflected XSS)

Ce type de faille cible une seule victime à un instant donné. Le contenu malveillant n’est
pas stocké sur le serveur Web mais livré à la victime via un lien malveillant. Typiquement,
l’attaquant postera un message à la victime via un système de messagerie interne au site Web
visé (forum, commentaire de blog…). Ce message contiendra un code malveillant JavaScript.
Lorsque la victime ouvrira ce message, le code JavaScript s’exécutera et permettra la
récupération de l’identifiant de session de la victime. Le tout étant redirigé vers un serveur
Web appartenant à l’attaquant. L’identifiant de session ainsi récupéré va permettre à
l’attaquant d’usurper l’identité de la victime sans connaître son mot de passe.

2- Les failles XSS persistantes (stored XSS)

Ce type de faille va impacter tous les utilisateurs qui vont visiter la page infectée. Dans ce
type de faille, l’attaquant va envoyer un contenu malveillant à une application Web, qui va le
stocker dans la base de données associée au site Web. Le contenu malveillant sera ainsi
retourné dans le navigateur de tous les utilisateurs qui visiteront la page visée. On peut citer
l’exemple d’un forum dans lequel les messages des utilisateurs ne sont pas protégés
(échappement). Si un membre poste un message contenant du JavaScript alors tous les
membres lisant ce message pourront être infectés.

Conséquences d’une attaque de type XSS

Les principales conséquences liées à l’exploitation d’une faille XSS sont les suivantes :

1. Vol du cookie d’identification

L’attaque XSS la plus courante consiste à détourner des comptes d'utilisateurs légitimes en
volant leurs cookies de session. Cela permet aux attaquants d'usurper l'identité des victimes et
d'accéder à toute information sensible ou fonctionnalité en leur nom.

2. Vol des identifiants de connexion

Un autre vecteur d'attaque pour XSS consiste à utiliser HTML et JavaScript afin de voler les
informations d'identification des utilisateurs, au lieu de leurs cookies. Cela peut être fait en
clonant la page de connexion de l'application Web, puis en utilisant la vulnérabilité XSS afin
de la servir aux victimes.

3. Accès à des informations sensibles ou réalisation d’opérations interdites

Un autre vecteur d'attaque puissant pour XSS consiste à l'utiliser pour exfiltrer des données
sensibles (par exemple des informations personnelles sensibles ou des données de titulaires de
cartes) ou pour effectuer des opérations non autorisées, telles que le siphonnage de fonds dans
un panier virtuel sur un site marchand vulnérable. Par exemple un site marchand comportant
un panier mal programmé pourra être exploité afin de permettre à l’attaquant de modifier le
panier (quantité, prix des produits). Concernant le vol d’information, si un attaquant XSS
parvient à voler un cookie de session, il peut dupliquer la session active de l'utilisateur et avoir
accès à tout ce que l'utilisateur est capable de faire sur un site Web : publier des messages sur
les réseaux sociaux, modifier les informations personnelles du compte, changer les mots de
passe, voler les informations sur les cartes bancaires, effectuer des virements bancaires,
acheter des produits sur un site de commerce électronique, etc.

Comment se protéger contre les XSS ?

Plusieurs techniques permettent d'éviter le XSS :

• Retraiter systématiquement le code HTML produit par l'application avant l'envoi au

navigateur ;
• Filtrer les variables affichées ou enregistrées avec des caractères '<' et '>'
(en CGI comme en PHP). De façon plus générale, donner des noms préfixés (avec par
exemple le préfixe "us" pour user string) aux variables contenant des chaines venant
de l'extérieur pour les distinguer des autres, et ne jamais utiliser aucune des valeurs
correspondantes dans une chaîne exécutable (en particulier une chaîne SQL, qui peut
aussi être ciblée par une injection SQL d'autant plus dangereuse) sans filtrage
préalable.
• En PHP :
o Utiliser la fonction htmlspecialchars() qui filtre les '<' et '>'
o Utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf
qu'elle filtre tous les caractères équivalents au codage HTML ou JavaScript.
• En ColdFusion :
o Utiliser la fonction HTMLEditFormat() qui remplace tous les caractères
spéciaux du langage HTML par leur référence d'entité
o Définir l'attribut scriptProtect du tag <cfapplication> pour protéger
automatiquement toutes les variables (form et/ou url et/ou cgi et/ou cookies)
d'un site
o Activer au niveau du serveur une protection globale (form, url, cgi et cookies)
par défaut de toutes les applications en cochant la case "Enable Global Script
Protection" du ColdFusion Administrator

Il existe des bibliothèques qui permettent de filtrer efficacement du contenu balisé issu de
l'utilisateur (systèmes de publication). Par ailleurs, il est également possible de se protéger des
failles de type XSS à l'aide d'équipements réseaux dédiés tels que les pare-feux applicatifs.
Ces derniers permettent de filtrer l'ensemble des flux HTTP afin de détecter les requêtes
suspectes.

Bonnes pratiques
Les bonnes pratiques suivantes peuvent être mises en place en tant que limitations ou
contremesures des vulnérabilités présentées en amont :

1.Validation des données saisies

La première méthode permettant d’empêcher les vulnérabilités XSS est l’échappement des
caractères suspects saisis par des utilisateurs. L’échappement de données signifie prendre les
données reçues par une application et s’assurer qu’elles sont sécurisées avant de les envoyer
vers l’utilisateur final. Cela permet de s’assurer que les données reçues par une page Web ne
pourront pas être interprétées de manière malveillante. Par exemple, les caractères suivants
seront échappés : <>/ empêchant ainsi l’exécution de code JavaScript. Les caractères à bannir
seront placés dans une liste noire. De même, les caractères autorisés doivent être placés dans
une liste blanche.
2. Encodage des données
L’encodage des données va consister à utiliser des fonctions permettant de filtrer des
symboles suspects en les remplaçant par leur équivalent
L’impact de la faille dans le système
Cette vulnérabilité a un impact une l’intégrité des données du système, la modification de
certains fichiers ou informations système est possible, mais l'attaquant n'a pas de contrôle sur
ce qui peut être modifié, ou la portée de ce que l'attaquant peut affecter est limitée.

Cette vulnérabilité a mis plus de 10 jours dans le système entre le moment où elle a été
introduite et le moment où elle a été corrigée