Articles
Comment se protéger des attaques XSS avec UBIKA Cloud Protector ?
Découvrez notre solution et ses fonctionnalités.
Qu’est-ce que la faille Cross-Site Scripting (XSS) ?
C’est quoi une attaque par xss ?
La vulnérabilité XSS ou Cross-site Scripting est une vulnérabilité qui affecte le côté client d’une application Web.
Cette vulnérabilité a été nommée pour la première fois en janvier 2000 par Microsoft et fait partie des vulnérabilités les plus courantes des applications Web sur internet (Cross-site scripting).
Selon l’OWASP, elle serait présente sur les deux tiers des sites internet (A7:2017-Cross-Site Scripting (XSS) | OWASP).
Les attaques XSS sont assez simple à effectuer : un pirate informatique injecte du code JavaScript sur la page d’une application Web et lorsque cette page sera visitée, le code sera exécuté dans le navigateur de l’utilisateur.
Malgré sa simplicité, cette faille se décline sous de nombreuses formes.
Quels sont les différents types de Cross-site Scripting ?
Faille XSS stockée:
Un nom explicite, car un contenu malveillant est enregistré dans une base de données et il apparaît à chaque fois que la page de l’application Web est visitée.
Faille XSS réfléchie (ou non persistantes):
Variante utilisant les paramètres des requêtes HTTP (POST & GET), l’attaque ne peut affecter que le navigateur des utilisateurs qui se rendent sur une page ou une URL forgée par le hacker
Faille Document Object Model (DOM-based):
Contrairement aux deux autres décrites précédemment, le code n’est pas envoyé à un serveur, mais exécuté directement par le navigateur de l’utilisateur.
Avec les attaques XSS stockées, le serveur stocke le script dans la base de données et ne le renvoie que lorsque le navigateur d’un utilisateur visite la page, ce type d’attaque s’effectue en deux temps.
Par conséquent, il est impossible pour la victime d’anticiper une attaque avant d’obtenir la page, ce qui fait de la vulnérabilité XSS stockée probablement la plus dangereuse de la famille XSS.
A l’inverse, les attaques XSS réfléchies et DOM-based doivent être placées dans les paramètres d’une requête, en particulier dans l’URL.
Cela signifie que ces deux attaques XSS peuvent être présentes dans des liens et sont utilisées par des hackers dans des emails, en utilisant un peu d’ingénierie sociale, il est possible de faire cliquer leur victime sur une URL et le script malveillant sera exécuté.
Les attaques XSS peuvent être effectuées de plusieurs manières, d’une balise <script> sur un forum au code dans l’attribut source d’une image
Quels sont les exemples d’impact des attaques Cross-Site Scripting (XSS) ?
Une attaque XSS peut avoir de nombreuses conséquences néfastes sur l’entreprise.
- Détournement de session : un pirate informatique peut rediriger le navigateur de la victime avec ces cookies sur son propre serveur, puis voler son identité sur le site Web vulnérable. Si la victime est un administrateur, le hacker pourra commettre toutes sortes de méfaits : vol de données, changements visuels / textuels sur le site, changer le rôle des autres utilisateurs, etc.
- Téléchargement de logiciels malveillants : le pirate informatique peut forcer le navigateur de sa victime à télécharger un fichier malveillant (virus, cheval de Troie, etc.).
- Defacing : Le pirate peut également modifier le contenu d’un site Web vulnérable et ajouter ce qu’il veut. (Défacement — Wikipédia (wikipedia.org)) Cette technique peut être utilisée pour ajouter du contenu illégal, des messages de propagande ou rendre le site complètement inutilisable.
Exemple d'attaque Cross-Site Scripting sur un serveur Web
1. Utilisation de base d’un chat
Pour illustrer l’utilisation d’une attaque XSS, j’utiliserai l’exemple d’une XSS stockée dans chat, cette variante étant la plus simple à appréhender, mais ayant des implications énormes pour une application Web et ses utilisateurs.
Prenons une fenêtre de discussion basique sans protection particulière, la page a une boîte où le message sera ajouté. Il existe un formulaire dans lequel vous pouvez écrire du texte.
Nous avons deux utilisateurs : Loris le hacker et Paul la victime.
Le but de Loris est de rediriger le navigateur de Paul sur son serveur Web pour voler ses cookies.
Commençons : Paul entame la conversation et Loris lui répond par un simple « Hello ».
Lorsqu’il cliquera sur le bouton « Post », le message sera envoyé au serveur.
Le serveur le stockera ensuite tel quel dans la base de données.
Au moment où le chat de Paul sera actualisé, le serveur renverra le message, qui sera inséré dans le code HTML de la page.
Le message de Loris sera donc affiché normalement sur son navigateur, tel que prévu par le site.
2. Comment détecter les vulnérabilités Cross-Site Scripting ?
Pour son prochain message, Loris va entourer « How are you ? » d’une balise HTML avec un attribut « style » censé afficher le texte en rouge.
De la même manière que pour le premier message, le serveur va stocker le message puis le renvoyer à Paul.
La balise « » sera considérée comme du code HTML et placée dans le DOM comme les autres balises.
Le message sera affiché en gras et en rouge sur le navigateur de l’utilisateur.
Cet exemple a été utilisé par Loris pour tester si l’application était vulnérable au XSS.
Il peut désormais effectuer une injection XSS avec du contenu malveillant.
Ce cas représente un exemple simple d’attaque XSS mais libre à l’attaquant d’imaginer la technique de son choix pour mener à bien son objectif (encodage, obfuscation du code, …).
3. Quel pourrait être un exemple d’attaque XSS ?
Loris sait maintenant que le chat est vulnérable à la XSS stockée et va alors décider de voler les cookies de Paul afin de se connecter à son compte.
Le Javascript comporte 2 éléments qui vont lui permettre d’arriver à ses fins :
- location permettant de rediriger le navigateur exécutant ce code vers la page web souhaitée.
- cookie contenant tous les cookies de l’utilisateurs sur le site actuel.
Avec le code ci-dessus, Loris va pouvoir rediriger le navigateur de Paul vers son propre serveur tout envoyant les cookies de ce dernier.
Il lui suffit alors de les récupérer pour avoir accès au compte de Paul sur le chat.
Ce cas représente un exemple simple d’injection XSS mais libre à l’attaquant d’imaginer la technique de son choix pour mener à bien son objectif (encodage, obfuscation du code, etc.).
Exemple de bonnes pratiques de l’Owasp
Quel est le meilleur moyen de se protéger contre une xss ?
L’Open Web Application Security Project (OWASP) fournit une liste de règles à appliquer pour protéger vos applications Web :
- Echapper les caractères HTML, CSS et Javascript est probablement la règle la plus sensée à appliquer, en effet, ne pas vérifier les entrées de l’utilisateur dans son code les conduira pour contenir du contenu Pour implémenter cette règle, vous pouvez utiliser des fonctions disponibles dans les différents langages de programmation ou utiliser des librairies destinées à nettoyer les entrées de l’utilisateur.
- Les Content Security Policy est une norme de sécurité informatique utilisée pour empêcher les attaques XSS et les injections de code (Content Security Policy — Wikipédia (wikipedia.org)).
Il est à noter que la plupart des frameworks modernes comme Angular, React ou Vue implémentent nativement ces fonctionnalités.
Ainsi, l’intégration d’un en-tête Content-Security-Policy dans les requêtes HTTP est également un bon moyen de protéger les navigateurs des utilisateurs car cela leur permet d’utiliser uniquement les ressources du serveur.
Les Content Security Policy doivent être bien configurées car elles peuvent amener à d’autres vulnérabilités de sécurité
Un autre en-tête intéressant est le X-XSS-Protection qui filtre automatiquement certaines attaques XSS, il est activé par défaut
Vous pouvez consulter toutes les recommandations de l’OWASP sur les failles XSS ici : Cross Site Scripting Prevention – OWASP Cheat Sheet Series
Protection XSS avec UBIKA Cloud Protector
Quelle fonction permet d’éviter spécifiquement les attaques de type XSS ?
Pour protéger une application Web contre les attaques XSS, UBIKA Cloud Protector peut faire deux choses :
Le « Blacklisting » est utilisée à tous les niveaux de protection :
Si UBIKA Cloud Protector détecte un pattern habituellement utilisé pour exploiter une faille XSS, la requête sera immédiatement bloquée et redirigée.
IMAAAGE
La « Scoring List » active sur les niveaux Advanced et High de protection :
UBIKA Cloud Protector va analyser la requête et incrémenter un score au fur et à mesure des patterns malicieux rencontrés.
A la fin de l’analyse, si le score est supérieur à la limite autorisée la requête est bloquée et redirigée.
Cette méthode à l’avantage d’être beaucoup plus fine et d’éviter les faux positifs.
