Différences

Ci-dessous, les différences entre deux révisions de la page.

--- sio:bloc3:attaques:xss [2025/12/09 09:06] – créée jcheron
+++ sio:bloc3:attaques:xss [2026/10/05 00:58] (Version actuelle) – [Erreurs à éviter] jcheron
@@ Ligne 1: / Ligne 1: @@
-====== XSS ======
+====== Résumé des attaques XSS ======
-===== Exemple d'attaque =====
-Ce texte ne sera jamais affiché
+===== Définition =====
+Une **XSS** (*Cross-Site Scripting*) est une faille qui permet à du contenu non fiable d’être interprété comme du code par le navigateur, dans le contexte d’un site vulnérable.
+Elle survient souvent lorsqu’une application affiche une donnée utilisateur sans l’échapper ni la traiter selon son contexte.
+===== Principaux types =====
+  * **XSS réfléchie** : une donnée reçue dans une requête est réaffichée immédiatement dans la page.
+  * **XSS stockée** : une donnée est enregistrée — par exemple un commentaire — puis affichée à d’autres utilisateurs.
+  * **XSS basée sur le DOM** : du code côté navigateur transmet une donnée non fiable à une API qui l’interprète comme du HTML ou du code.
+===== Exemple simple =====
+Une insertion avec ''innerHTML'' peut interpréter la valeur comme du HTML :
+<sxh javascript>
+// À éviter avec une donnée non fiable
+element.innerHTML = valeurUtilisateur;
+</sxh>
+Si la donnée doit être affichée comme du texte, préférer ''textContent'' :
+<sxhjavascript>
+// Recommandé pour afficher du texte
+element.textContent = valeurUtilisateur;
+</sxh>
+===== Risques =====
+Une XSS peut notamment permettre de modifier le contenu affiché, de tromper un utilisateur ou d’effectuer certaines actions avec ses droits. L’impact dépend des fonctionnalités et des protections de l’application.
+===== Prévention =====
+  * **Échapper les données à l’affichage**, selon leur contexte : HTML, attribut, URL, etc.
+  * Utiliser l’échappement automatique fourni par les moteurs de templates ou frameworks.
+  * Éviter d’insérer des données non fiables avec ''innerHTML'' ou d’autres API qui interprètent des chaînes.
+  * Si l’application doit autoriser du HTML, utiliser une bibliothèque de **sanitisation spécialisée**, maintenue et configurée de façon restrictive.
+  * Ajouter une **Content Security Policy (CSP)** comme défense complémentaire.
+  * Protéger les cookies de session avec les attributs adaptés, comme ''HttpOnly'' et ''Secure''.
+===== Erreurs à éviter =====
+<WRAP round important>
+  * Se fier uniquement à une liste noire de caractères ou de balises.
+  * Croire que la validation des données remplace l’encodage à l’affichage.
+  * Nettoyer du HTML avec des expressions régulières ou du code maison.
+  * Considérer CSP, ''HttpOnly'' ou un pare-feu applicatif comme un remplacement à la correction de la faille.
+</WRAP>
+===== À retenir =====
+<WRAP tip round>
+Traiter toute donnée externe comme non fiable.
+  * Pour afficher du texte, utiliser une méthode qui l’insère comme texte ;
+  * pour autoriser du HTML, recourir à une sanitisation spécialisée.
+</WRAP>