Position actuelle: Accueil> Derniers articles> Est-il vraiment efficace d'utiliser HTMLSpecialChars pour empêcher les attaques du CSRF? Analyse des principes de protection et des techniques d'utilisation

Est-il vraiment efficace d'utiliser HTMLSpecialChars pour empêcher les attaques du CSRF? Analyse des principes de protection et des techniques d'utilisation

M66 2025-07-18

L'utilisation réelle de htmlSpecialChars ()

htmlSpecialChars () est une fonction pour empêcher les XS (attaques de scripts inter-sites). Son objectif est de convertir des caractères spéciaux dans HTML (comme < , > , " , & ) en entités HTML pour empêcher les scripts malveillants soumis par les utilisateurs d'être exécutés dans la page. Par exemple:

 <?php
$user_input = '<script>alert("XSS")</script>';
echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
?>

Le résultat de la sortie est:

 &lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;

Ce code empêche efficacement l'injection de javascript malveillante en HTML, mais cela a peu de relation directe avec la défense des attaques du CSRF.

Analyse du principe de l'attaque du CSRF

CSRF utilise le "statut de connexion" de l'utilisateur. L'attaquant incite l'utilisateur à cliquer sur un lien ou à accéder à une image / iframe, et fait une demande en utilisant l'état de connexion actuel de l'utilisateur sur un certain site Web. Par exemple:

 <img src="https://m66.net/delete_account.php" />

Si l'utilisateur est connecté sur m66.net et que le serveur n'a fait aucune vérification, cette demande peut en fait supprimer le compte d'utilisateur.

La clé de cette attaque est que l'utilisateur n'a pas informé une demande de changement d'état et que le serveur fait confiance à la demande.

Raisons pour lesquelles htmlSpecialCars () ne peut pas empêcher le CSRF

HtmlSpecialCars () agit dans le "stade de sortie" et empêche principalement le navigateur de analyser les scripts malveillants. Les attaques CSRF sont des demandes initiées automatiquement ou induisent par le navigateur de l'utilisateur, et même si la page n'a pas de sortie, elle peut être déclenchée.

En d'autres termes, CSRF est une "demande de déguisement de l'identité de l'utilisateur" et n'a rien à voir avec le fait que le contenu de sortie a été échappé. Par conséquent, HTMLSpecialCars () n'empêche pas les attaques CSRF.

La bonne façon de se défendre contre le CSRF

  1. Utilisation du jeton CSRF

Le moyen le plus efficace consiste à ajouter un jeton CSRF généré de manière aléatoire au formulaire et à le vérifier lors du traitement de la demande. Par exemple:

 <?php
session_start();
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
?>
<form method="POST" action="https://m66.net/update_profile.php">
    <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>" />
    <!-- Autres champs de forme -->
    <button type="submit">soumettre</button>
</form>
<?php
} elseif ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
        die("Demande illégale！");
    }
    // Effectuer des opérations de mise à jour
}
?>

  1. Vérifiez l'en-tête du référence ou de l'origine

Bien qu'il ne puisse pas être entièrement invoqué, il peut aider à déterminer si la demande est légale dans certains scénarios. Par exemple:

 <?php
$referer = $_SERVER['HTTP_REFERER'] ?? '';
if (parse_url($referer, PHP_URL_HOST) !== 'm66.net') {
    die("Source illégale");
}
?>

  1. Utilisez l'attribut Cookie Samesite

Les navigateurs modernes aident à empêcher des tiers de demander des cookies en définissant l'attribut cookie de Samesite = Strict ou Samesite = LAX :

 setcookie('session_id', $value, [
    'samesite' => 'Strict',
    'secure' => true,
    'httponly' => true
]);
Connexe