XSS pour les nuls

Aujourd'hui, nous allons jeter un coup d'œil à l'origine de l'une des vulnérabilités les plus courantes et exploitées sur Internet : le XSS, également connu sous le nom de cross-site scripting. Si vous n'êtes pas familier avec la sécurité web, ne vous inquiétez pas, je vais tout vous expliquer ! Commençons !

Comment fonctionne le web

Mais avant d'expliquer ce qu'est un XSS, nous devons comprendre comment fonctionne une page web pour acquérir les bases.

Schema expliquant le fonctionnement du web

JavaScript et définition globale de XSS

Dans cette introduction, j'ai parlé de JavaScript, un langage web permettant d'ajouter des fonctionnalités dynamiques à une page. C'est ici que notre attaque XSS intervient. Pour en donner une définition générale :

Le code malveillant est ensuite exécuté par le navigateur des utilisateurs qui visitent la page. Cela peut permettre à l'attaquant de voler des informations confidentielles telles que des mots de passe, des cookies de session ou même des données bancaires. Plus d'informations sur les impacts plus tard.

Fonctionnement d'une XSS basique

La XSS fonctionne sur le principe de l'injection : un attaquant fournit une entrée non fiable à un programme, qui l'exécute ensuite, induisant une action malveillante. Les injections sont un vecteur d'attaque courant en cybersécurité, toujours dans le top 3 du top 10 de l'OWASP (un document de sensibilisation standard pour les développeurs et la sécurité des applications Web).

Il existe 3 types de XSS :

1. XSS stockée,
2. XSS réfléchie,
3. XSS basée sur le DOM

Nous allons passer en revue chaque type, c'est parti !

XSS stockée

Imaginez que vous soyez derrière votre écran, en train d'utiliser un site web qui vous permet de poster des commentaires sur des articles.

Si le site n'a pas une protection suffisante contre les attaques XSS stockées, un attaquant peut poster un commentaire contenant un script malveillant qui sera stocké sur le serveur (dans la base de données des commentaires, par exemple).

Fonctionnement d'une XSS stockée

Cela se produit lorsque qu'un attaquant parvient à insérer un code malveillant (généralement sous forme d'un script JavaScript) dans une page Web stockée sur le serveur, qui est ensuite exécuté sur les navigateurs des utilisateurs accédant à la page.

XSS réfléchie

Imaginons à nouveau que vous utilisiez un site web qui vous permet de chercher des produits en entrant des termes de recherche dans une barre de recherche.

Lorsque vous ouvrez la page de résultats, votre navigateur exécute automatiquement le script malveillant sans que vous en ayez conscience.

Fonctionnement d'une XSS réfléchie

Si vous avez bien compris, vous pensez probablement que cette XSS nécessite une interaction de l'utilisateur pour fonctionner, car elle n'est pas stockée. Et vous avez raison. C'est pourquoi les attaquants utilisent souvent le phishing avec des liens malveillants contenant une XSS réfléchie pour faire exécuter la charge utile par la victime.

XSS basée sur le DOM

Petite mise en garde, c'est la XSS la plus compliquée à comprendre. Mais avant de parler de la XSS elle-même, un point sur ce qu'est le DOM est nécessaire.

Qu'est-ce que le DOM ?

Pour simplifier, le DOM est une hiérarchie d'objets qui représentent les éléments HTML (par exemple, les balises <p>, <div>, <img>, etc.) et peuvent être manipulés à l'aide de méthodes et de propriétés JavaScript.

Arbre DOM

Normalement, avec cette phrase, vous devriez commencer à comprendre d'où provient la vulnérabilité.

En effet, qui dit modification dynamique du DOM avec JavaScript dit possibilité d'exploiter ces modifications dynamiques.

Lorsque l'utilisateur ouvre la page web, le code malveillant est exécuté directement sur le navigateur de l'utilisateur.

Par exemple, si une page HTML contient ce morceau de code vulnérable :

<script>
    document.write(“Le site est:” + document.location.href + “.”);
</script>

Un attaquant peut ajouter le code JavaScript à l'URL pointant vers cette page vulnérable.

#<script>alert(document.cookie)</script>

Une fenêtre pop-up est alors affichée sur le navigateur de la victime qui aura imprudemment cliqué sur ce lien URL.

Fonctionnement d'une DOM BASED XSS

Impacts

À quoi peut servir les XSS ?

• Exécuter un code arbitraire sur le navigateur d'une victime peut permettre à un attaquant de voler des cookies (lorsque les cookies ne sont pas sécurisés, les attaquants peuvent les voler et les utiliser pour s'authentifier en tant que victimes sans avoir besoin de connaître leur mot de passe).
• Enregistrement des frappes (les attaquants peuvent espionner les victimes et récupérer leurs frappes clavier).
• Phishing (les attaquants peuvent modifier l'apparence et le comportement du site, incitant les victimes à envoyer des informations sensibles aux serveurs des attaquants).

Mesures correctives

• Filtrer les données entrantes. Lorsque des entrées utilisateur sont reçues, filtrez aussi strictement que possible en fonction de ce qui est attendu ou de ce qui constitue une entrée valide.
• Encoder les données en sortie (en fonction du contexte). Lorsque des données contrôlables par l'utilisateur sont envoyées dans les réponses HTTP, encodez la sortie pour éviter qu'elle ne soit interprétée comme du contenu actif.
  • < devient : <
  • > devient : >
  • < devient : \u003c
  • > devient : \u003e
• Utiliser des en-têtes de réponse appropriées. Pour éviter les XSS dans les réponses HTTP qui ne sont pas censées contenir de HTML ou de JavaScript, vous pouvez utiliser les en-têtes Content-Type et X-Content-Type-Options pour vous assurer que les navigateurs interprètent les réponses comme vous l'avez prévu.
• Politique de sécurité du contenu (CSP) - est la dernière ligne de défense qui peut être utilisée pour atténuer la gravité des vulnérabilités XSS qui surviennent toujours. CSP vous permet de contrôler divers éléments, tels que le chargement de scripts externes et l'exécution de scripts en ligne.
  Pour déployer CSP, vous devez inclure un en-tête de réponse HTTP appelé "Content-Security-Policy" avec une valeur contenant votre politique.

  
  Un exemple de CSP est le suivant :
  
  default-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';
  
  Cette politique spécifie que les ressources telles que les images et les scripts ne peuvent être chargées que depuis la même origine que la page principale. Par conséquent, même si un pirate parvient à injecter une charge utile XSS, il ne peut charger que des ressources depuis l'origine actuelle. Cela réduit considérablement les chances pour un attaquant d'exploiter la vulnérabilité XSS.

Fonctionnement des CSP

Resources