Par Thierry Albain (SQLI) : Les injections XSS : une menace en puissance
Mon dernier billet s'intéressait aux attaques des sites Web par injections SQL (lire l'article du 21/01/2009 : L'importance de se prémunir contre les attaques par injections SQL).
Ces attaques visent à prendre possession du site en modifiant les requêtes SQL vérifiant l'authentification de l'utilisateur qui se connecte. Elles peuvent être plus dévastatrices en altérant la base de données des comptes utilisateurs voire même en altérant le serveur hébergeant le SGBD.
Un autre type d'attaque par injection vise principalement les utilisateurs afin de prendre possession de leurs données personnelles. Cette technique, appelée le XSS, pour Cross Site Scripting, permet à un pirate de :
Exécuter un script malveillant dans un navigateur Web client,
Insérer des balises <script>, <object>, <applet>, <form>, <embed>, <iframe>, <a>?
Voler des informations de session Web et des cookies d'authentification,
Accéder à l'ordinateur client.
Considérons une page Web dans laquelle un utilisateur peut saisir ses informations personnelles, comme son login, son adresse email et un texte libre. Ce genre de page se trouve sur les forums de discussion par exemple.
Un cas à prendre en compte : le texte saisi dans un formulaire est un code Javascript
Il n'y a aucune raison, a priori, de tester le contenu du texte libre. Seulement, ce qu'on oublie parfois, c'est que ce texte sera affiché, tel quel, dans la liste des réponses de chaque utilisateur du forum.
Si ce texte est un script Javascript, par exemple, l'affichage de ce texte dans la liste des réponses du forum déclenchera l'exécution de ce script. Le serveur ne subit, apparemment, aucune altération. Seul l'utilisateur, qui navigue sur la page contenant la liste des réponses du forum, sera affecté.
Prenons comme exemple de script :
<script>document.location.replace?</script>
L'utilisateur qui navigue sur le forum sera automatiquement redirigé sur un autre site. Cet autre site peut être visuellement identique et peut demander à l'utilisateur de s'authentifier à nouveau, ce qui va permettre au pirate de voler l'identifiant et le mot de passe de cet utilisateur.
Conclusion
La règle de base à suivre est donc de ne jamais faire confiance aux données saisies par un utilisateur. Toute entrée doit être considérée comme malicieuse et donc doit être testée avant sa sauvegarde dans la base de données du site.