Vulnérabilités du web : XSS

Sécurité Site e-commerce Site internet

pratiques securite site web

Voici la faille sans aucun doute la plus répandue du web : le Cross-Site Scripting (XSS). Vous trouverez un bon nombre d’articles sur le sujet mais pour vous éviter de chercher, et puisque j’ai envie d’écrire sur le sujet, voici tous ce qu’il faut savoir !

Qu’est-ce que c’est ?

Il s’agit d’injecter du code dans les requêtes renvoyées par le site à ses visiteurs. Ainsi, la victime est l’utilisateur et non le site en lui-même. Partant de ce constat, beaucoup de webmasters ne se soucient pas des XSS. Pourtant, des attaques par XSS peuvent être très dommageables pour votre site web. Pour mieux comprendre de quoi il s’agit, prenons un exemple simple.

Sur un site quelconque, les membres peuvent éditer un profil qui est visible par les autres membres. Le site renvoie donc, dans le code de la page, certaines informations contrôlables par l’utilisateur. Cet utilisateur pourrait y entrer un script JS qui serait exécuter sur les ordinateurs des visiteurs de son profil.

Les deux types de XSS

Il existe deux types de faille XSS. Tout d’abord, la Persistent XSS est une faille XSS qui, comme son nom l’indique, est permanente sur le site. Une fois l’attaque réalisée, les prochains visiteurs d’une page exécuteront le code injectés. Aucune autre étape n’est requise. C’est l’exemple du profil ci-dessus par exemple.

Un autre type de XSS qui peut sembler beaucoup moins dangereux mais qui peut tout de même être utilisés efficacement porte le nom de Non-Persistent XSS ou Reflective XSS. Dans ce cas-ci, il faut forcer la victime a envoyé une requête précise. Les données mal-filtrées font partie de la requête envoyée par le client, par exemple, une variable GET.

Une autre distinction entre en ligne de compte. Les DOM-Based XSS sont des XSS où la vulnérabilité se trouve côté client et non côté serveur. Ainsi, un script JS utilisant une partie de l’URL pour la renvoyer dans le DOM sans la filtrer correctement peut amener à une DOM-Based Reflective XSS.

Exploitation de cette vulnérabilité

Dès lors que le pirate peut injecter du code chez les visiteurs de votre site, il peut en résulter des conséquences catastrophiques. Tout d’abord, le hacker peut se faire passer pour vous et vous dé-crédibiliser. Il peut contrôler l’entièreté de ce qui est affiché sur l’écran de sa victime.

S’il contrôle le navigateur de votre visiteur, il en contrôle aussi l’action sur le site. Il peut ainsi faire en sorte que le navigateur du visiteur lui fasse faire n’importe quoi sur le site. Pire ! Imaginez maintenant que ce visiteur, c’est vous et que vous êtes connectés sur la partie administration de votre site web.

Toute l’information confidentielle contenue sur votre site web et accessible seulement par le visiteur est maintenant accessible au pirate. Ainsi même s’il n’a pas à proprement parler un accès en lecture/écriture à la base de données, en passant par des visiteurs, il peut presque avoir les mêmes privilèges qu’avec un accès direct à la DB.

Méthodes de protection

Il suffit simplement de filtrer correctement toute donnée contrôlable ou même influençable par une tierce personne qui est renvoyée dans le code de l’application. En PHP, on utilisera la fonction htmlentities() ou <%=h @variable %> en Ruby on Rails.

Malheureusement, étant donné que l’injection ne se fait pas systématiquement dans du code HTML, on ne peut pas donner de réponse miracle et les fonctions de filtrages à mettre en place dépendront totalement de l’endroit où l’injection de données utilisateurs se fait.

La méthode est simple mais rarement bien implémentée par les webmasters.

Le partage c'est la vie !

Article publié le 8 décembre 2015 par weclain