Se protéger de la faille XSS (Cross-site scripting)
Qu’est-ce que la faille XSS
XSS vient de Cross-Site Scripting et comme l’acronyme CSS était déjà pris pour Cascading Style Sheets, on a utilisé un X pour « cross » (croix en anglais).
La faille consiste à injecter un script arbitraire dans une page pour provoquer une action bien définie. Les autres utilisateurs exécutent le script sans s’en rendre compte dès l’ouverture de la page.
Cross veut également dire traverser, car l’un des buts de la faille est d’exécuter un script permettant de transmettre des données depuis un site vers un autre.
Ce problème se situe principalement au niveau des cookies, car on peut par exemple récupérer les cookies d’un site A depuis un site B. On peut ainsi récupérer les cookies de n’importe qui, même de l’administrateur d’un site.
Notez par ailleurs qu’on peut exploiter la faille XSS en JavaScript mais aussi avec d’autres langages.
Que peut-on faire avec une faille XSS ?
On distingue deux types de failles XSS:
1) XSS permanent
C’est lorsque le script est stocké sur le serveur hébergeant le site faillible (base de données). Il est donc récupéré et exécuté à tout moment sur le site par n’importe quel utilisateur. La simple visite de la page contenant le script suffit effectivement à l’exécuter.
2) XSS non permanent
Le script est souvent intégré à une URL et est exécuté sans être stocké sur un serveur. Cela arrive par exemple en faisant une recherche. Si l’on actualise la page, le terme cherché ne reste pas, et le script ne s’exécute donc que « sur le coup ».
Que peut-on faire avec la faille XSS ?
On peut distinguer plusieurs possibilités non exhaustives d’exploitation de cette faille :
- Une redirection de la page afin de nuire aux utilisateurs ou pour tenter une attaque de phishing.
- Voler des sessions ou des cookies. (Donc se faire passer pour un autre utilisateur pour exécuter des actions)
- Rendre le site inaccessible en utilisant des alertes en boucle (dénis de service) ou tout autre moyen nuisible.
Comment savoir si mon site est faillible ?
Lorsque vous transmettez des données (commentaires, posts d’articles, recherche d’un terme etc) via votre site, si un script transmis comme:
<script type="text/javascript">alert('test');</script>
s’exécute, c’est-à-dire que si la boite de dialogue « test » apparaît, votre site est faillible.
L’exemple est très simplifié, car l’exploitation peut être faisable même si la boite « test » n’apparaît pas. En effet, Javascript est un langage de programmation à part entière, bien intégré avec HTML, et les possibilités d’exécution de code sont nombreuses, comme lors du chargement d’une image.
Exemple d’exploitation de faille XSS
Le premier ver XSS appellé Samy s’est propagé sur myspace en 2005. Tous les utilisateurs qui visitaient une page spécifique re-propageaient à leur tour le ver.
Je ne peux pas citer toutes les possibilités, mais sachez que ça m’est arrivé de voir des failles XSS dans les pseudonymes des membres (j’ai eu mon moment de gloire avant de me faire bannir). L’administrateur se basait seulement sur un code JavaScript qui vérifiait si le pseudo contenait des lettres et chiffres, mais ne vérifiait pas du côté serveur.
Comment se protéger de la faille XSS
Au même titre qu’il existe plusieurs moyens d’exploiter la faille XSS, il existe plusieurs moyens de s’en protéger.
L’idée générale est cependant la même : filtrer les entrées utilisateurs (en commençant par ne faire confiance A RIEN de ce qui vient du navigateur/de l’utilisateur).
Il faut par exemple utiliser les fonctions : php htmlspecialchars() qui filtre les ‘<‘ et ‘>’ ou htmlentities() qui filtre toutes les entités html.
Ces fonctions doivent être utilisées sur des entrées utilisateurs qui s’afficheront plus tard sur votre site. Si elle ne sont pas filtrées, les scripts comme ceux que nous avons vus plus haut s’exécuteront avec tout le mal qui s’en suit.
Voici un exemple d’utilisation de cette fonction avec un paramètre POST appelé « nom » qu’un navigateur nous envoie (typiquement un formulaire demandant un nom):
<?php echo htmlspecialchars($_POST['nom']); // echo affiche les données sur un page, du coup on protège l'affichage avec la fonction htmlspecialchars?>Au possible, il faut placer des cookies avec le paramètre HttpOnly, empêchant leur récupération avec JavaScript (Attention elle n’est pas forcément supportée par tous les navigateurs).
Envie d’en apprendre plus sur les failles web ?
Cette faille et bien d’autres est vue en détail dans mon cours vidéo sur les tests d’intrusion web.
Nous allons parler des fondamentaux : fonctionnement d’HTTP, d’HTTPs, de DNS et de l’architecture web de manière générale.
Nous allons également mettre en place un laboratoire de test avec des machines virtuelles pour héberger et scanner nos propres sites vulnérables créés sur mesure, afin d’apprendre sans rien casser.
Nous allons bien sûr parler de toutes les failles web (XSS, CSRF, SQL, LFI, RFI, …etc) en suivant le Top 10 OWASP mais aussi de tout ce qui gravite autour de la sécurité web : dénis de service, mauvaises configurations, données personnelles, reconnaissance, etc…
Impatient de commencer avec vous, je vous invite à rejoindre le cours dès maintenant : https://cyberini.com/cours/hacking-ethique-tests-intrusion-web/
