Attaque XSS

🔒 Comprendre les attaques XSS (Cross-Site Scripting)

1. Introduction simple

Une attaque XSS (Cross-Site Scripting) consiste à injecter du code malveillant (souvent du JavaScript) dans une page web.
Ce code s’exécute dans le navigateur des visiteurs sans qu’ils s’en rendent compte.

Concrètement, si un site n’est pas protégé, un attaquant peut faire en sorte que ses scripts s’exécutent chez les autres utilisateurs pour voler leurs données (cookies, sessions) ou modifier l’affichage du site.

Exemple concret : un site affiche les commentaires des utilisateurs sans filtrage.
Un pirate poste un commentaire contenant du JavaScript.
Tous ceux qui lisent la page exécutent ce script à leur insu.

Conséquences : vol de cookies de session, redirection vers un faux site de connexion, modification de contenu, phishing, etc.

2. Les différents types d’attaques XSS

• XSS réfléchi (Reflected XSS) :
  L’attaque passe par l’URL ou un formulaire. Le code malveillant est renvoyé immédiatement par le serveur dans la page.

  Exemple : https://exemple.com/search?q=<script>alert('XSS')</script>
  Si le site affiche directement le paramètre q sans filtrer, le script s’exécute.

• XSS stocké (Stored XSS) :
  Le code malveillant est enregistré dans la base de données et affiché à chaque visite.

  Exemple : un commentaire contenant <script>alert('Hacked!')</script> sera exécuté par tous les visiteurs.

• XSS DOM-based :
  Le script malveillant exploite directement le code JavaScript du site qui manipule le DOM (Document Object Model).

  Exemple : si du JavaScript lit location.hash et l’insère dans la page sans échapper les caractères, un attaquant peut injecter un script.

3. Exemples concrets en PHP

Exemple vulnérable

<?php
// search.php
$q = $_GET['q'] ?? '';
echo "Résultat de recherche pour : $q";
?>
  

⚠️ Si on visite search.php?q=<script>alert('XSS')</script>,
un pop-up s’affiche dans le navigateur. Le code injecté s’exécute.

Exemple corrigé

<?php
$q = $_GET['q'] ?? '';
// Échapper les caractères spéciaux avant d’afficher
echo "Résultat de recherche pour : " . htmlspecialchars($q, ENT_QUOTES, 'UTF-8');
?>
  

✅ Ici, <script> devient du texte inoffensif et ne s’exécute pas.

4. Bonnes pratiques pour se protéger

• Échapper toutes les données utilisateur avant affichage :
  utiliser htmlspecialchars() en PHP, ou les mécanismes intégrés de frameworks (Twig, Blade…).
• Valider et filtrer les entrées : ne jamais faire confiance aux données envoyées par le client.
• Limiter l’usage de HTML fourni par l’utilisateur :
  si besoin d’autoriser du HTML (ex. dans un éditeur de texte), utiliser une bibliothèque de nettoyage (HTML Purifier).
• Utiliser les en-têtes HTTP de sécurité :
  Content-Security-Policy (CSP) pour restreindre les scripts exécutables.
• Ne jamais insérer directement des données dans du JavaScript sans les encoder.
• Mettre à jour les frameworks et bibliothèques : beaucoup intègrent déjà une protection XSS.

5. Exercice pratique 🧩

1. Créer une page PHP vulnérable qui affiche le paramètre q d’une URL sans filtrage.
2. Tester en appelant la page avec ?q=<script>alert('XSS')</script>.
3. Corriger la faille avec htmlspecialchars() et vérifier que le script ne s’exécute plus.
4. Bonus : tester Content-Security-Policy en ajoutant l’en-tête HTTP suivant :

   header("Content-Security-Policy: default-src 'self'");