CSRF (Cross-Site Request Forgery) en PHP

🔍 Comment fonctionne une attaque CSRF ?

Scénario type :

1. La victime est connectée à vulnerable-site.com (son cookie de session est actif).
2. Elle visite un site malveillant (ou clique sur un lien dans un email) contenant :

   <!-- Code HTML malveillant (ex: dans une iframe invisible) -->
   <img src="https://vulnerable-site.com/change-email?new_email=hacker@evil.com" width="0" height="0">

3. Le navigateur envoie automatiquement la requête avec le cookie de session de la victime.
4. Le serveur exécute l’action sans vérifier l’origine de la requête.

Pourquoi ça marche ?

• Les cookies sont envoyés automatiquement par le navigateur pour les requêtes vers le même domaine.
• Le serveur ne fait pas la différence entre une requête légitime et une requête forcée.

🛡️ Solutions pour se protéger en PHP

1. Utiliser des tokens CSRF

Principe : Ajouter un token unique et imprévisible à chaque formulaire, et le vérifier côté serveur.

Exemple avec PHP natif :

// Génération du token (à faire une fois par session)
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// Dans le formulaire HTML
<form action="transfer.php" method="POST">
  <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">
  <input type="text" name="amount">
  <input type="submit" value="Envoyer">
</form>

// Vérification côté serveur
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF token invalid!");
}

Avec une librairie (recommandé) :

// Utilisation de paragonie/csrf-magic (composer require paragonie/csrf-magic)
require 'vendor/autoload.php';
$csrf = new \ParagonIE\AntiCSRF\AntiCSRF;

// Dans le formulaire
<input type="hidden" name="csrf_token" value="<?php echo $csrf->insertToken(); ?>">

// Vérification
try {
    $csrf->validateRequest();
} catch (\ParagonIE\AntiCSRF\AntiCSRFException $e) {
    die("CSRF validation failed!");
}

2. Vérifier l’en-tête Referer ou Origin

Limite : Peut être contourné si l’attaquant utilise un sous-domaine ou un protocole différent (HTTP vs HTTPS).

$referer = $_SERVER['HTTP_REFERER'] ?? '';
$allowed_domain = 'https://votre-site.com';

if (strpos($referer, $allowed_domain) !== 0) {
    die("Requête non autorisée (mauvais Referer).");
}

3. Configurer les cookies avec SameSite

Solution la plus simple (mais nécessite HTTPS) :

// Dans php.ini ou via .htaccess
session.cookie_samesite = "Strict" // ou "Lax"

// Ou en PHP
ini_set('session.cookie_samesite', 'Strict');
session_start();

• Strict : Le cookie n’est envoyé que pour les requêtes vers le même site (idéal pour les zones sensibles).
• Lax : Autorise les liens externes (ex: depuis un email), mais bloque les requêtes POST cross-site.

4. Privilégier les requêtes POST pour les actions sensibles

Règle d’or :

• GET = Récupération de données (idempotent).
• POST = Modification de données (doit être protégé par CSRF).

Exemple de middleware PHP pour forcer POST :

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    die("Méthode non autorisée.");
}

5. Utiliser des frameworks modernes

Les frameworks PHP populaires intègrent déjà des protections CSRF :

• Laravel : Token CSRF automatique via @csrf dans les formulaires.
• Symfony : Composant Security/CSRF avec csrf_token().
• WordPress : Fonction wp_nonce_field().

Exemple avec Laravel :

// Dans un formulaire Blade
<form method="POST" action="/transfer">
    @csrf <!-- Génère un token CSRF -->
    <input type="text" name="amount">
</form>

🎯 Bonnes pratiques supplémentaires

🔧 Outils pour tester les vulnérabilités CSRF

1. Extensions navigateur :
   • Cookie-Editor : Pour modifier les cookies et tester les protections SameSite.
   • Burp Suite : Intercepter/modifier les requêtes pour simuler une attaque.
2. Scripts Python :

   # Exemple avec requests pour tester une vulnérabilité CSRF
   import requests
   url = "https://vulnerable-site.com/change-email"
   cookies = {"sessionid": "volé_ou_deviné"}  # Cookie de la victime
   data = {"email": "hacker@evil.com"}
   response = requests.post(url, cookies=cookies, data=data)
   print(response.text)  # Vérifie si l'action est exécutée

3. Outils automatisés :
   • OWASP ZAP : Scanner de vulnérabilités CSRF.
   • Nikto : nikto -host exemple.com -C all (recherche de formulaires non protégés).

📌 Résumé des actions clés pour les développeurs PHP

🚨 Exemple réel d’exploitation CSRF (cas historique)

Attaque sur YouTube (2008) :

• Un pirate a exploité une faille CSRF pour forcer les utilisateurs à s’abonner à des chaînes malveillantes.
• Méthode :
  • Un lien piégé (<img src="https://youtube.com/subscribe?channel=HACKER">) était partagé sur des forums.
  • Les victimes connectées à YouTube s’abonnaient automatiquement en visitant la page.
• Correctif : YouTube a ajouté des tokens CSRF et limité les actions sensibles aux requêtes POST.

📚 Ressources pour approfondir

• OWASP CSRF Prevention Cheat Sheet
• PHP The Right Way - Security
• Paragonie’s Anti-CSRF Library

💡 Message final :

"Le CSRF est une attaque sournoise car elle exploite un comportement normal du web : la confiance dans les cookies. La bonne nouvelle ? Avec des tokens CSRF et une configuration stricte des cookies, vous pouvez éliminer 99% des risques. Ne négligez pas cette protection – elle prend 5 minutes à implémenter et peut sauver votre application."

❓ Questions fréquentes

1. "Les tokens CSRF suffisent-ils ?" → Oui, si ils sont uniques par session/formulaire et vérifiés côté serveur. Mais combinez-les avec SameSite pour une protection optimale.

2. "Pourquoi ne pas bloquer toutes les requêtes cross-origin ?" → Certains sites légitimes ont besoin de requêtes cross-origin (ex: API publiques). Les tokens CSRF permettent une protection ciblée.

3. "Mon site est en HTTP, puis-je utiliser SameSite ?" → Non, SameSite nécessite HTTPS. Passez en HTTPS avant de l’implémenter.