Comment prévenir les attaques CSRF en PHP

Concept CSRF : CSRF Cross-Site Request Forgery (Cross-Site Request Forgery) , comme les attaques XSS, présente un préjudice énorme. Vous pouvez le comprendre comme ceci :

.

Un attaquant usurpe votre identité et envoie une requête malveillante en votre nom. Cette requête est tout à fait légale au serveur, mais elle complète une opération attendue par l'attaquant, comme utiliser votre Envoyer des e-mails et des messages en votre nom. , volez votre compte, ajoutez des administrateurs système et même achetez des biens, transférez de la monnaie virtuelle, etc. (Apprentissage recommandé : Programmation PHP de l'entrée à la maîtrise)

Par exemple : Web A est un site Web présentant des vulnérabilités CSRF, Web B est un site Web malveillant construit par un attaquant et l'utilisateur C est Web A Utilisateurs légitimes du site Web.

Défense contre les attaques CSRF :

Il existe actuellement trois stratégies principales pour se défendre contre les attaques CSRF : vérifier le champ HTTP Referer : ajouter un jeton à l'adresse de la requête ; et vérifiez-le ; Attributs personnalisés dans l'en-tête et vérifiez.

(1) Vérifiez le champ HTTP Referer

Selon le protocole HTTP, il y a un champ appelé Referer dans l'en-tête HTTP, qui enregistre l'adresse source du Requête HTTP. Dans des circonstances normales, la demande d'accès à une page restreinte sécurisée provient du même site Web. Par exemple, si vous devez accéder à http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory, l'utilisateur doit d'abord se connecter. vers bank.example puis passez par Cliquez sur un bouton de la page pour déclencher l'événement de transfert.

A ce moment, la valeur Referer de la demande de transfert sera l'URL de la page où se trouve le bouton de transfert, généralement une adresse commençant par le nom de domaine bank.example. 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.

(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 . Toutes les informations d'authentification de l'utilisateur contenues dans la demande existent dans les cookies, de sorte que les pirates peuvent utiliser directement 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 dans la requête HTTP et créer un intercepteur côté serveur pour vérifier le jeton dans la requête ou si le contenu du jeton est incorrect. est considéré comme possible. La demande est rejetée en raison d'une attaque CSRF.

(3) Personnaliser les attributs dans l'en-tête HTTP et vérifier

Cette méthode utilise également des jetons et effectue une vérification, ce qui est différent de la méthode précédente Oui, le jeton n'est pas placé dans la requête HTTP sous forme de paramètre, mais il est placé dans l'attribut personnalisé de 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 demande 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 fuite du jeton vers d'autres sites Web. via le référent.

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!