Web8 : Exploits XSS - Partie 2 : XSS stocké

Dans l’article précédent, nous avons découvert les erreurs XSS (Cross Site Scripting) et l’exploitation réelle de XSS Reflected. Il existe un autre type de XSS considéré comme plus dangereux : le XSS stocké.

Contrairement à Reflected, qui attaque directement quelques victimes ciblées par les pirates, Stored XSS cible davantage de victimes. Cette erreur se produit lorsque l'application Web ne vérifie pas minutieusement les données d'entrée avant de les enregistrer dans la base de données (ici, j'utilise ce concept pour faire référence à la base de données, au fichier ou à d'autres zones qui stockent les données de l'application Web).

Avec la technique Stored XSS, les hackers ne l’exploitent pas directement mais doivent le faire en au moins 2 étapes.

Premièrement, les pirates utilisent des points de saisie non filtrés (formulaire, saisie, zone de texte...) pour insérer du code dangereux dans la base de données.

Ensuite, lorsque l'utilisateur accède à l'application Web et effectue des opérations liées à ces données enregistrées, le code du pirate informatique sera exécuté sur le navigateur de l'utilisateur.

À ce stade, le hacker semble avoir atteint son objectif. Pour cette raison, la technique Stored XSS est également appelée XSS de second ordre.

Le scénario d'exploitation est décrit comme suit :

Reflected XSS et Stored XSS présentent deux différences majeures dans le processus d'attaque.

• Premièrement, pour exploiter Reflected XSS, le pirate informatique doit tromper la victime pour qu'elle accède à son URL. Quant au Stored XSS, cela n'est pas nécessaire : après avoir inséré le code dangereux dans la base de données de l'application, le pirate n'a plus qu'à attendre que la victime y accède automatiquement. Pour les victimes, c’est tout à fait normal car elles ne savent pas que les données auxquelles elles accèdent ont été infectées.
• Deuxièmement, l'objectif du pirate informatique sera plus facile à atteindre si, au moment de l'attaque, la victime est toujours dans la session de l'application Web. Avec Reflected XSS, un pirate informatique peut convaincre ou tromper la victime pour qu'elle se connecte et accède à l'URL qu'il fournit pour exécuter du code malveillant. Mais Stored XSS est différent, car le code malveillant a été stocké dans la base de données Web, donc chaque fois que l'utilisateur accède aux fonctions associées, le code malveillant sera exécuté, et très probablement ces fonctions nécessitent une authentification. Connectez-vous d'abord, donc évidemment pendant ce temps l'utilisateur est toujours dans la session.

De ces éléments, on peut voir que Stored XSS est beaucoup plus dangereux que Reflected XSS, les sujets concernés peuvent être tous les utilisateurs de cette application Web. Et si la victime a un rôle administratif, il existe également un risque de détournement du Web.