Cross-Site Scripting (XSS) et CSRF

Le script intersite (XSS) est une vulnérabilité d’injection côté client dans laquelle un attaquant injecte des scripts malveillants dans des pages web consultées par d’autres utilisateurs. Contrairement à l’injection SQL, qui cible le Server, le XSS cible le navigateur de la victime. Lorsque le navigateur exécute le script de l’attaquant, celui-ci dispose des mêmes privilèges que les scripts légitimes de la page, ce qui permet le détournement de session, le vol d’identifiants et la diffusion de logiciels malveillants.

Le XSS réfléchi se produit lorsqu’un script malveillant est intégré à une URL et que le Server le « reflète » immédiatement dans la réponse HTTP sans encodage approprié. La victime est incitée (souvent au moyen d’un lien d’hameçonnage) à cliquer sur l’URL conçue à cet effet, ce qui amène son navigateur à exécuter le script de l’attaquant. Le XSS réfléchi n’est pas persistant : il ne s’exécute que lorsque la victime clique sur le lien malveillant.

Le XSS stocké (persistant) intègre un script malveillant dans la base de données de l’application, par exemple dans un commentaire ou une publication de forum. Chaque utilisateur qui consulte ce Content voit le script s’exécuter dans son navigateur, ce qui rend le XSS stocké bien plus dangereux que le XSS réfléchi. Le XSS fondé sur le DOM se produit entièrement dans le navigateur lorsque JavaScript côté client lit des données contrôlées par l’attaquant depuis le DOM (par exemple, le fragment d’URL) et les réécrit dans la page de manière non sécurisée.

La principale défense contre le XSS est l’encodage de la sortie : convertir les caractères spéciaux en leurs équivalents sous forme d’entités HTML (<, >, &) avant de les afficher dans le navigateur. Un en-tête Content Security Policy (CSP) limite les scripts autorisés à s’exécuter et constitue une importante défense secondaire. La validation des entrées (par liste d’autorisation) doit également être appliquée côté serveur.

La falsification de requête intersite (CSRF) exploite la confiance qu’un site web accorde au navigateur d’un utilisateur authentifié. Un attaquant incite le navigateur d’une victime à envoyer une requête authentifiée indésirable vers un site sur lequel la victime est connectée. Comme le navigateur joint automatiquement les cookies de session, le Server cible considère la requête comme légitime. Les attaques CSRF courantes permettent de transférer des fonds, de modifier des adresses e-mail ou de changer les paramètres d’un compte.

Imaginez qu’un utilisateur soit connecté à sa banque sur bank.com. Un attaquant lui envoie un e-mail contenant une balise d’image cachée : <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Lorsque l’e-mail est ouvert, le navigateur charge automatiquement l’URL de l’image et envoie la requête de virement avec le cookie de session bancaire de la victime. La banque la traite comme une requête légitime.

La défense la plus efficace contre le CSRF est un jeton CSRF : une valeur unique et imprévisible intégrée à chaque formulaire et vérifiée côté serveur. Comme l’attaquant ne peut pas lire le jeton depuis une autre origine (politique de même origine), les requêtes falsifiées ne contiennent pas de jeton valide et sont rejetées. L’attribut de cookie SameSite (SameSite=Strict ou Lax) empêche également les navigateurs d’envoyer des cookies lors de requêtes intersites.

Le XSS et le CSRF sont souvent confondus, mais ils ciblent des éléments différents. Le XSS injecte un script malveillant qui s’exécute dans le navigateur de la victime, en exploitant la confiance de l’utilisateur envers le site web. Le CSRF falsifie des requêtes du navigateur de la victime vers un site de confiance, en exploitant la confiance du site envers le navigateur de l’utilisateur. Le XSS peut servir à voler des jetons CSRF et à enchaîner efficacement les deux vulnérabilités.

Les indicateurs de cookie offrent d’importantes mesures d’atténuation contre le XSS. L’indicateur HttpOnly empêche JavaScript d’accéder au cookie via document.cookie, ce qui rend plus difficile le vol de jetons de session, même en présence d’un XSS. L’indicateur Secure garantit que les cookies sont transmis uniquement via HTTPS, empêchant leur interception sur des canaux non chiffrés. Ces deux indicateurs doivent être définis sur tous les cookies de session comme mesure de défense en profondeur.

Les testeurs en sécurité recherchent le XSS en injectant des charges utiles de test dans chaque champ de saisie, paramètre d’URL, en-tête HTTP et champ JSON. Une sonde simple est <script>alert(1)</script> : si une boîte d’alerte apparaît, le XSS est confirmé. Des outils comme Burp Suite automatisent l’analyse du XSS, et OWASP ZAP fournit une analyse active gratuite. Le XSS fondé sur le DOM nécessite une analyse de JavaScript côté navigateur plutôt qu’une inspection de la réponse du Server.

Les attaques XSS ont causé des dommages importants dans le monde réel. Le ver Samy (2005) s’est propagé sur MySpace en 20 heures en exploitant un XSS stocké pour s’auto-propager à plus d’un million de profils. Les attaques XSS peuvent voler des jetons de session afin de détourner entièrement des comptes, rediriger les utilisateurs vers des sites d’hameçonnage, diffuser des Exploit de navigateur (téléchargements furtifs) et modifier le contenu des pages pour afficher de fausses informations aux utilisateurs ciblés.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : le XSS injecte des scripts dans des pages consultées par d’autres utilisateurs, le CSRF incite des navigateurs authentifiés à envoyer des requêtes falsifiées, et l’encodage de la sortie, CSP, les jetons CSRF et l’attribut de cookie SameSite constituent les principales défenses. Nous allons maintenant étudier l’authentification défaillante et la désérialisation non sécurisée.