Maison > Article > développement back-end > Yii Framework Official Guide Series 51 - Thème spécial : Mesures de sécurité (Sécurité)
Attaque par scripts intersites (appelée XSS), c'est-à-dire , les applications Web collectent des informations auprès des utilisateurs. Données utilisateur. Les attaquants injectent souvent du JavaScript, VBScript, ActiveX, HTML ou Flash dans des applications Web vulnérables pour confondre les visiteurs et collecter des informations sur les visiteurs. Par exemple, un système de forum mal conçu peut afficher les entrées des utilisateurs sans les vérifier. Un attaquant peut injecter un morceau de code JavaScript malveillant dans le contenu de la publication. De cette manière, lorsque d'autres visiteurs liront cet article, ces codes JavaScript pourront être exécutés sur l'ordinateur du visiteur.
L'une des mesures les plus importantes pour prévenir les attaques XSS est : Inspection du contenu avant d'afficher le contenu saisi par l'utilisateur. Par exemple, vous pouvez échapper le code HTML dans le contenu. Mais dans certains cas, cette méthode n'est pas recommandée, car elle désactive toutes les balises HTML.
Yii intègre HTMLPurifier et fournit aux développeurs un composant très utile CHtmlPurifier, qui encapsule la classe HTMLPurifier. Il peut supprimer tout code malveillant du contenu audité grâce à des fonctions efficaces d'examen, de sécurité et de liste blanche, et garantir que le contenu filtré après filtrage répond aux normes.
Le composant CHtmlPurifier peut être utilisé comme widget ou filtre. Lorsqu'il est utilisé comme widget, CHtmlPurifier peut filtrer en toute sécurité le contenu affiché dans la vue. Ce qui suit est un exemple de code :
3985325355f9adb62c26998b2d6e1066beginWidget('CHtmlPurifier'); ?> //...这里显示用户输入的内容... 3985325355f9adb62c26998b2d6e1066endWidget(); ?>
Attaque de falsification de requête intersite (CSRF en abrégé), c'est-à-dire que lorsque le navigateur de l'utilisateur visite un site Web malveillant, l'attaquant amène le navigateur de l'utilisateur à lancer une requête spécifiée par l'attaquant vers un site Web de confiance. . Par exemple, un site Web malveillant possède une image, et l'adresse src
de cette image pointe vers un site Web de banque : http://www.php.cn/
. Si l'utilisateur visite cette page Web malveillante après s'être connecté au site Web de la banque, le navigateur de l'utilisateur enverra une instruction au site Web de la banque. Le contenu de cette instruction peut être « transférer 10 000 yuans sur le compte de l'attaquant ». Les attaques intersites profitent d'un site Web spécifique auquel l'utilisateur fait confiance, tandis que les attaques CSRF, au contraire, profitent de l'identité spécifique de l'utilisateur sur un site Web.
Pour éviter les attaques CSRF, vous devez vous rappeler une chose : GET
Les requêtes sont uniquement autorisées à récupérer des données et ne peuvent modifier aucune donnée sur le serveur. La requête POST
doit contenir des valeurs aléatoires qui peuvent être reconnues par le serveur pour garantir que la source des données du formulaire et la destination des résultats en cours d'exécution sont les mêmes.
Yii implémente un mécanisme de prévention CSRF pour aider à prévenir les attaques basées sur POST
. Le cœur de ce mécanisme est de définir une donnée aléatoire dans le cookie, puis de la comparer avec la valeur correspondante dans les POST
données soumises par le formulaire.
Par défaut, la prévention CSRF est désactivée. Si vous souhaitez l'activer, vous pouvez éditer la section CHttpRequest du composant dans la configuration de l'application.
Exemple de code :
return array( 'components'=>array( 'request'=>array( 'enableCsrfValidation'=>true, ), ), );
Pour afficher un formulaire, Veuillez utiliser CHtml::form au lieu d'écrire vous-même du code HTML. Parce que CHtml::form peut automatiquement intégrer un élément masqué dans le formulaire. Cet élément masqué stocke les données aléatoires nécessaires à la vérification. Ces données peuvent être envoyées au serveur pour vérification lorsque le formulaire est soumis.
Il est très important de protéger les cookies contre les attaques. Parce que l'ID de session est généralement stocké dans un cookie. Si l'attaquant vole un identifiant de session valide, il peut utiliser les informations de session correspondant à cet identifiant de session.
Voici quelques précautions :
Vous pouvez utiliser SSL pour créer un canal sécurisé et envoyer le cookie d'authentification uniquement via une connexion HTTPS. De cette manière, l’attaquant ne peut pas décrypter le cookie envoyé.
Définissez le délai d'expiration des cookies, faites de même pour tous les cookies et jetons de session. Cela réduit les risques d'être attaqué.
Empêche les attaques de code intersites, car cela peut déclencher du code arbitraire dans le navigateur de l'utilisateur, ce qui peut divulguer les cookies de l'utilisateur.
Vérifiez le contenu du cookie lorsque le cookie change.
Yii implémente un mécanisme de vérification des cookies pour empêcher la modification des cookies. Après activation, la vérification HMAC des valeurs des cookies peut être effectuée.
La vérification des cookies est désactivée par défaut. Si vous souhaitez l'activer, vous pouvez éditer la section CHttpRequest du composant dans la configuration de l'application.
Exemple de code :
return array( 'components'=>array( 'request'=>array( 'enableCookieValidation'=>true, ), ), );
Assurez-vous d'utiliser Yii Données de cookies authentifiés. Utilisez le composant cookies intégré de Yii pour les opérations sur les cookies, n'utilisez pas $_COOKIES
.
// 检索一个名为$name的cookie值 $cookie=Yii::app()->request->cookies[$name]; $value=$cookie->value; ...... // 设置一个cookie $cookie=new CHttpCookie($name,$value); Yii::app()->request->cookies[$name]=$cookie;
Ce qui précède est le contenu de la série 51 du guide officiel du Yii Framework - Sujet spécial : mesures de sécurité (sécurité). Pour plus de contenu connexe, veuillez prêter attention au . Site Web chinois PHP (www.php.cn) !