Introduction aux problèmes de sécurité courants dans le développement front-end

Questions fréquemment posées :

(Partage de vidéos d'apprentissage : Vidéo de programmation)

Attaque de script intersite (1. XSS) Attack)

XSS (Cross Site Scripting), attaque de cross-site scripting. XSS est l'une des technologies d'attaque Web courantes. L'attaque dite par script intersite fait référence à ce qui suit : des attaquants malveillants injectent du code de script malveillant dans des pages Web. Lorsque les utilisateurs parcourent ces pages Web, le code malveillant est exécuté, ce qui peut être exécuté. causer du tort aux utilisateurs. Diverses attaques telles que le vol d'informations sur les cookies et le détournement de session.

Solution :

(1) Filtrage d'entrée. Ne faites jamais confiance aux entrées de l'utilisateur et effectuez certains filtres sur les données saisies par l'utilisateur. Par exemple, si les données saisies sont conformes au format attendu, tel que le format de date, le format d'e-mail, le format de code du numéro de téléphone

, etc. Cela peut fournir une défense préliminaire contre les vulnérabilités XSS. Les mesures ci-dessus limitent uniquement le côté Web. Les attaquants peuvent toujours contourner les restrictions d'entrée frontales en utilisant des outils de capture de paquets tels que Fiddler et modifier la requête pour injecter des scripts d'attaque.

Par conséquent, le serveur backend doit filtrer ou échapper aux caractères spéciaux dangereux après avoir reçu les données saisies par l'utilisateur, puis les stocker dans la base de données. (2) Codage de sortie. Les données sorties du serveur vers le navigateur

peuvent être codées ou échappées à l'aide des fonctions de sécurité du système pour empêcher les attaques XSS. En PHP, il existe deux fonctions htmlentities() et htmlspecialchars() qui peuvent répondre aux exigences de sécurité. La méthode d'encodage JavaScript correspondante

peut utiliser JavascriptEncode. (3) Codage de sécurité. Le développement doit essayer d'éviter la réécriture, la redirection ou d'autres opérations sensibles des documents du client Web, et éviter d'utiliser les données client. Ces opérations doivent être implémentées côté serveur en utilisant autant que possible des pages dynamiques. (4) Cookie HTTP uniquement. La méthode de défense la plus efficace pour empêcher les attaques XSS de voler les cookies des utilisateurs. Lorsqu'une application Web définit un cookie, définissez son attribut sur HttpOnly,

, pour empêcher les cookies de la page Web d'être volés par du JavaScript malveillant côté client et protéger les informations des cookies de l'utilisateur. (5) WAF (Web Application Firewall), pare-feu d'application Web, sa fonction principale est de prévenir les attaques de vulnérabilité Web courantes telles que les chevaux de Troie Web,

XSS et CSRF. Développé par des sociétés tierces, il est populaire dans les environnements d'entreprise.

2. Falsification de requêtes intersites (attaque CSRF)

CSRF (Cross Site Request Forgery), c'est-à-dire la falsification de requêtes intersites, est une attaque Web courante, mais de nombreux développeurs le font J'en ai peur. Très étrange. CSRF est également le type d'attaque de site Web le plus facilement négligé en matière de sécurité Web.

Principe de l'attaque CSRF : L'utilisateur victime du processus d'attaque CSRF se connecte au site Web A, saisit ses informations personnelles et enregistre le cookie généré par le serveur. localement. Cliquez ensuite sur un lien malveillant construit par l'attaquant sur le site Web A pour accéder au site Web

B. Le site Web B transporte ensuite les informations du cookie de l'utilisateur pour visiter le site Web B. Cela donne l'impression que le site Web A est la propre visite de l'utilisateur, ainsi Pour effectuer une série d'opérations, la plus courante est le transfert

Solution :

(1) Code de vérification. Lors de l'interaction entre l'application et l'utilisateur, notamment dans les étapes essentielles telles que les transactions sur le compte, l'utilisateur est obligé de saisir un code de vérification pour compléter la demande finale. Dans des circonstances normales, les codes de vérification sont suffisamment efficaces pour contenir les attaques

CSRF. Cependant, l’ajout de codes de vérification réduit l’expérience utilisateur et le site Web ne peut pas ajouter de codes de vérification à toutes les opérations. Par conséquent, les codes de vérification ne peuvent être utilisés que comme moyen auxiliaire pour définir des codes de vérification à des points commerciaux clés. (2) Vérification du référent.

Le référent HTTP fait partie de l'en-tête. Lorsque le navigateur envoie une requête au serveur Web, il apporte généralement les informations du référent pour indiquer au serveur à partir de quelle page il est lié. Le serveur peut les utiliser pour en obtenir. informations pour le traitement

Raison. Les attaques CSRF peuvent être défendues en vérifiant la source de la requête. Le référent d'une requête normale a certaines règles. Par exemple, le référent d'une soumission de formulaire doit être une requête initiée sur cette page. Par conséquent, en vérifiant si la valeur du référent de l'en-tête http

correspond à cette page, nous pouvons déterminer s'il s'agit d'une attaque CSRF. Mais dans certains cas, comme pour passer de https à http, le navigateur n'enverra pas le référent pour des raisons de sécurité et le serveur ne pourra pas vérifier. Si

d'autres sites Web du même domaine que ce site Web présentent des vulnérabilités XSS, les attaquants peuvent injecter des scripts malveillants dans d'autres sites Web. Les victimes qui saisissent de telles URL dans le même domaine seront également attaquées. Pour les raisons ci-dessus, Referer Check ne peut pas être entièrement fiable comme principal moyen de défense contre le CSRF

. Cependant, l'apparition d'attaques CSRF peut être surveillée via Referer Check. (3) Jeton anti-CSRF. La solution actuelle relativement complète consiste à ajouter Anti-CSRF-Token, c'est-à-dire à ajouter un jeton généré aléatoirement en tant que paramètre dans la requête HTTP

lors de l'envoi d'une requête, et à établir un intercepteur sur le serveur pour vérifier cela. jeton. Le serveur lit la valeur du jeton dans le cookie de domaine actuel du navigateur et vérifie si le jeton

dans la requête et la valeur du jeton dans le cookie existent et sont égaux avant de considérer qu'il s'agit d'une requête légitime. A défaut, la demande sera considérée comme illégale et le service sera refusé. Cette méthode est beaucoup plus sûre que la vérification du référent. Le jeton peut être généré une fois que l'utilisateur

s'est connecté et placé dans la session ou le cookie, puis le serveur retire le jeton de la session ou du cookie à chaque demande. , et Le jeton de cette demande est comparé. Du fait de l'existence du token, l'attaquant ne peut plus construire

Créez une URL complète pour implémenter l'attaque CSRF. Cependant, lorsqu'il s'agit du problème de coexistence de plusieurs pages, lorsqu'une certaine page consomme le jeton, les formulaires des autres pages enregistrent toujours le jeton consommé, et une erreur de jeton

se produira lorsque les formulaires des autres pages sont soumis.

3. Attaque par injection SQL

Injection SQL (SQL Injection), lorsque l'application transmet SQL (Structured Query Language, Structured Query Language) à la base de données backend, l'attaquant va SQL des commandes sont insérées dans des formulaires Web pour soumettre ou saisir des noms de domaine ou des chaînes de requête pour les requêtes de page, incitant finalement le serveur à exécuter des commandes SQL malveillantes

Solution :

(1) Empêcher. Des informations système sensibles ont été divulguées. Définissez l'option php.ini display_errors=off pour empêcher que des erreurs d'informations sensibles ne soient affichées sur la page Web après qu'une erreur se soit produite dans le script php, donnant ainsi aux attaquants la possibilité d'en profiter. (2) Évasion de données. Définissez l'option php.ini magic_quotes_gpc=on, qui ajoutera automatiquement tous les "(guillemets simples), "(guillemets doubles), (barres obliques inverses), caractères vides, etc. dans les variables soumises devant. Ou utilisez la fonction mysql_real_escape() ou addlashes() pour échapper aux paramètres d'entrée. (3) Ajouter une vérification de liste noire ou de liste blanche. La vérification de la liste blanche fait généralement référence à la vérification si l'entrée de l'utilisateur correspond au type, à la longueur, à la plage de valeurs attendus ou à d'autres normes de format. contient un contenu malveillant évident, la demande de l'utilisateur sera rejetée. Lors de l'utilisation de la vérification par liste blanche, elle est généralement combinée avec la vérification par liste noire

4. La vulnérabilité de téléchargement de fichiers<. par les pirates l dvbbs6.0. la vuln de t peut utilis pour obtenir directement webshell. le niveau dommage est extr une courante dans intrusions actuelles. cette permet aux utilisateurs n quoi. permettre un attaquant d du contenu dangereux ou code malveillant et sur serveur. principe fichiers : parce que fonction ne limite pas strictement suffixe type fichier permettant ainsi des fichiers. en php arbitraires via r accessible web capable transmettre ces vous pouvez ex scripts serveur distant>

Solution :

. (1) Vérifiez si le serveur détermine le type et le suffixe du fichier téléchargé. (2) Définissez une liste blanche des types de fichiers téléchargés, c'est-à-dire que seuls les types de fichiers de la liste blanche peuvent être téléchargés. Le répertoire de téléchargement interdit l'analyse des scripts pour éviter les attaques secondaires des attaquants. Vulnérabilité d'information La vulnérabilité d'information signifie que CGI affiche les paramètres d'entrée tels qu'ils sont et que l'attaquant trompe l'utilisateur en modifiant les paramètres d'entrée. Détails :

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!