1. Le Cross-Site Scripting (XSS)

La vulnérabilité XSS permet à un attaquant d’injecter du code JavaScript malveillant dans des pages web légitimes consultées par d’autres utilisateurs. Lorsque la victime consulte la page, son navigateur exécute le script avec les privilèges du site légitime :

  • XSS Réfléchi (Reflected XSS) : Le script hostile est injecté via un paramètre de requête HTTP (ex. paramètre de recherche) et immédiatement renvoyé dans la réponse du serveur.
  • XSS Stocké (Stored / Persistent XSS) : Le script hostile est enregistré de manière permanente dans la base de données (ex. champ de commentaire d’un forum, profil utilisateur) et exécuté à chaque affichage de la ressource par un visiteur.
  • Conséquences : Vol des cookies de session (détournement de compte), redirection vers des sites de phishing, ou modification frauduleuse du DOM affiché.
  • Contre-mesures : Échappement systématique des sorties HTML (contextual output encoding), utilisation de l’attribut HttpOnly sur les cookies de session pour interdire leur lecture par JavaScript, et déploiement d’une politique CSP stricte.

2. Le Cross-Site Request Forgery (CSRF)

Le CSRF force un utilisateur authentifié sur une application web à exécuter à son insu une action non désirée (par exemple transférer des fonds ou changer son adresse courriel de contact). L’attaquant trompe le navigateur de la victime pour qu’il envoie une requête HTTP forgée vers le site cible, en joignant automatiquement les cookies de session valides de l’utilisateur.

Défenses modernes : Jetons anti-CSRF aléatoires, cryptographiquement robustes et validés côté serveur pour chaque formulaire de modification, combinés à l’utilisation systématique de l’attribut SameSite=Lax ou SameSite=Strict sur les cookies de session.

3. Le Server-Side Request Forgery (SSRF)

Le SSRF est une vulnérabilité critique particulièrement redoutable dans les infrastructures Cloud modernes (AWS, Azure, GCP, OpenStack). Elle permet à un attaquant d’amener le serveur applicatif à envoyer une requête HTTP vers une destination interne arbitraire non accessible publiquement depuis Internet :

// Exemple : Une fonction permet de charger un avatar depuis une URL fournie :
// URL légitime : https://cdn.exemple.ch/avatar.jpg
// URL injectée par l'attaquant : http://169.254.169.254/latest/meta-data/iam/security-credentials/
// Résultat : Le serveur va lui-même interroger l'API de métadonnées interne du cloud
// et renvoyer les clés d'accès administrateur à l'attaquant !

Protection : Liste blanche stricte des domaines autorisés, interdiction formelle de contacter les adresses IP privées (RFC 1918) et les adresses de liaison locale (Link-Local 169.254.0.0/16).

Laboratoire d’expérimentation : Identifiez la différence de comportement entre un cookie configuré avec l’attribut HttpOnly; Secure; SameSite=Strict et un cookie sans aucun attribut lors d’une tentative de vol de session via document.cookie.

PreviousNext