Maison >Opération et maintenance >Sécurité >Quelles sont les méthodes de défense du CSRF ?
Les méthodes de défense Csrf incluent : 1. Vérifiez le champ HTTP Referer ; 2. Ajoutez un jeton à l'adresse de la demande et vérifiez 3. Personnalisez les attributs dans l'en-tête HTTP et vérifiez. CSRF est une méthode d'attaque qui contraint les utilisateurs à effectuer des opérations involontaires sur l'application Web à laquelle ils sont actuellement connectés.
csrf est une méthode d'attaque qui oblige les utilisateurs à effectuer des opérations involontaires sur l'application Web actuellement connectée.
Méthodes de défense CSRF :
Il existe actuellement trois stratégies principales pour se défendre contre les attaques CSRF :
1. Vérifiez le champ HTTP Referer ;
2. Dans l'adresse de la demande, ajoutez un jeton et vérifiez ;
3. Personnalisez les attributs dans l'en-tête HTTP et vérifiez.
Parlons-en en détail :
(1) Vérifiez le champ HTTP Referer
Selon le protocole HTTP, il y a un champ dans l'en-tête HTTP appelé Referer, qui enregistre l'adresse source de la requête HTTP. En règle générale, les demandes d’accès à une page sécurisée et restreinte proviennent du même site Web. Si un pirate informatique souhaite mettre en œuvre une attaque CSRF sur le site Web d'une banque, il ne peut créer une requête que sur son propre site Web. Lorsqu'un utilisateur envoie une demande à la banque via le site Web du pirate informatique, le référent de la demande pointe vers le propre site Web du pirate informatique. .
Ainsi, pour se défendre contre les attaques CSRF, le site Web de la banque n'a qu'à vérifier sa valeur Referer pour chaque demande de transfert. S'il s'agit d'un nom de domaine commençant par bank.example, cela signifie que la demande émane de la banque. site Web lui-même. Oui Légal. Si le Referer est un autre site web, il peut s'agir d'une attaque CSRF d'un hacker et la demande sera rejetée.
L'avantage évident de cette méthode est qu'elle est simple et facile à mettre en œuvre. Les développeurs ordinaires du site Web n'ont pas à se soucier des vulnérabilités CSRF. Il leur suffit d'ajouter un intercepteur à toutes les requêtes sensibles à la sécurité. la fin pour vérifier la valeur du Referer. Surtout pour le système existant actuel, il n'est pas nécessaire de modifier le code ni la logique existants du système actuel, il n'y a aucun risque et c'est très pratique.
(2) Ajoutez un jeton à l'adresse de la demande et vérifiez
La raison pour laquelle l'attaque CSRF réussit est que le pirate informatique peut complètement falsifier la demande de l'utilisateur, et tout les requêtes dans la requête Toutes les informations d'authentification de l'utilisateur existent dans les cookies, de sorte que les pirates peuvent directement utiliser les propres cookies de l'utilisateur pour passer la vérification de sécurité sans connaître les informations d'authentification.
Pour résister au CSRF, la clé est de mettre dans la requête des informations que les pirates ne peuvent pas falsifier, et ces informations n'existent pas dans le cookie. Vous pouvez ajouter un jeton généré aléatoirement en tant que paramètre à la requête HTTP et créer un intercepteur côté serveur pour vérifier le jeton. S'il n'y a pas de jeton dans la requête ou si le contenu du jeton est incorrect, on considère qu'il peut l'être. une attaque CSRF et la demande sera rejetée.
(3) Personnalisez les attributs dans l'en-tête HTTP et vérifiez
Cette méthode utilise également des jetons et effectue une vérification La différence par rapport à la méthode précédente est qu'ici au lieu de mettre. le jeton en tant que paramètre dans la requête HTTP, il le place dans un attribut personnalisé dans l'en-tête HTTP. Grâce à la classe XMLHttpRequest, vous pouvez ajouter l'attribut d'en-tête HTTP csrftoken à toutes les requêtes de ce type en même temps et y insérer la valeur du jeton.
Cela résout l'inconvénient de l'ajout d'un jeton à la requête dans la méthode précédente. Dans le même temps, l'adresse demandée via XMLHttpRequest ne sera pas enregistrée dans la barre d'adresse du navigateur et il n'y a pas lieu de s'inquiéter de la question. le jeton est divulgué sur d'autres sites Web via le référent.
Cependant, cette méthode présente de grandes limites. La requête XMLHttpRequest est généralement utilisée pour l'actualisation asynchrone partielle de la page dans la méthode Ajax. Toutes les requêtes ne peuvent pas être lancées avec cette classe, et la page obtenue via cette requête de classe ne peut pas être enregistrée par le navigateur, de sorte qu'elle soit en avant ou en arrière. , et une actualisation peut être effectuée, une collecte et d'autres opérations gênent les utilisateurs.
De plus, pour les systèmes existants qui n'ont pas de protection CSRF, si vous souhaitez utiliser cette méthode de protection, vous devez modifier toutes les requêtes en requêtes XMLHttpRequest. Cela réécrira presque tout le site Web, ce qui est sans aucun doute coûteux. . C'est inacceptable.
Si vous souhaitez en savoir plus sur les problèmes connexes, vous pouvez visiter le site Web chinois php.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!