Résumé des problèmes de sécurité PHP

                                                                                                           

1-XSS

Cross-Site Scripting (attaque par script intersite), appelé XSS, est une attaque par injection de code . Les attaquants injectent des scripts malveillants dans le site Web cible afin qu'ils puissent s'exécuter sur le navigateur de l'utilisateur. À l'aide de ces scripts malveillants, les attaquants peuvent obtenir des informations sensibles des utilisateurs telles que les cookies, SessionID, etc., mettant ainsi en péril la sécurité des données.

Source

• Informations UGC des utilisateurs

• Liens de tiers

• Paramètres d'URL

• Paramètres POST

• Référent (peut provenir de sources non fiables)

• Cookie (peut être injecté à partir d'autres sous-domaines)

Échapper, filtrer, limiter la longueur

Injection 2-SQL

Utilisez les instructions SQL pour vous connecter sans compte et même falsifier la base de données.

Exemples d'attaques

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

Comment se défendre contre l'injection SQL
1. Vérifiez le type et le format des données des variables
2. Filtrez les symboles spéciaux
3. Liez les variables et utilisez la précompilation déclaration

3-CSRF

CSRF fait généralement référence à la falsification de requêtes intersites
Le nom complet de l'attaque CSRF est requête intersite la contrefaçon (cross site request forgery), est une utilisation malveillante d'un site Web

CSRF profite d'un site Web de confiance en déguisant les demandes d'utilisateurs de confiance. L'attaquant vole votre identité et envoie des demandes à des tiers en votre nom. Le site Web envoie des requêtes malveillantes. Ce que CRSF peut faire inclut utiliser votre identité pour envoyer des e-mails, des SMS, effectuer des transferts de transactions, etc., et même voler votre compte.

Par exemple :
Comme suit : Web A est un site Web avec une vulnérabilité CSRF, Web B est un site Web malveillant créé par un attaquant et l'utilisateur C est un utilisateur légitime du site Web Web A

3-1 Le principe et le processus de l'attaque CSRF sont les suivants :

1. L'utilisateur C ouvre le navigateur, visite le site Web de confiance A, entre. le nom d'utilisateur et le mot de passe pour demander la connexion au site Web A ;

2. Une fois les informations de l'utilisateur vérifiées, le site Web A génère des informations de cookie et les renvoie au navigateur. le site Web A et peut envoyer des requêtes au site Web A normalement ;

3. Avant que l'utilisateur ne quitte le site Web A, il ouvre une page TAB dans le même navigateur pour visiter le site Web B

4. B reçoit la demande de l'utilisateur, il renvoie un code offensant et émet une demande d'accès au site Web B. Site tiers A

5 Après avoir reçu ces codes offensants, le navigateur transporte des informations sur les cookies et envoie une demande. vers le site Web A selon la demande du site Web B à l'insu de l'utilisateur. Le site Web A ne sait pas que la demande est réellement initiée par B, il traitera donc la demande avec les autorisations de C en fonction des informations du cookie de l'utilisateur C, provoquant ainsi l'exécution du code malveillant du site Web B.

3-2 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 ; jeton à l'adresse de la demande et vérification ; personnaliser les attributs dans les en-têtes HTTP et vérifier.

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 HTTP demande. 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. . Par conséquent, pour se défendre contre les attaques CSRF, le site Web de la banque doit uniquement 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 provient du site Web de la banque lui-même et qu'elle est légale. 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.

Cependant, cette méthode n’est pas infaillible. La valeur de Referer est fournie par le navigateur. Bien que le protocole HTTP ait des exigences claires, chaque navigateur peut avoir des implémentations différentes de Referer, ce qui ne garantit pas que le navigateur lui-même ne présente aucune faille de sécurité. La méthode de vérification de la valeur du Referer repose sur un tiers (c'est-à-dire le navigateur) pour garantir la sécurité. Théoriquement, cela n'est pas sûr. En fait, pour certains navigateurs, comme IE6 ou FF2, il existe déjà des méthodes pour altérer la valeur du Referer. Si le site Web bank.example prend en charge le navigateur IE6, un pirate informatique peut définir la valeur Referer du navigateur de l'utilisateur sur une adresse commençant par le nom de domaine bank.example, afin qu'il puisse réussir la vérification et mener une attaque CSRF.

Même si vous utilisez les navigateurs les plus récents, les pirates ne peuvent pas altérer la valeur Referer, et cette méthode pose toujours des problèmes. Étant donné que la valeur Referer enregistrera la source d'accès de l'utilisateur, certains utilisateurs pensent que cela portera atteinte à leur propre vie privée. Certaines organisations craignent en particulier que la valeur Referer ne divulgue certaines informations de l'intranet de l'organisation vers le réseau externe. Ainsi, les utilisateurs eux-mêmes peuvent paramétrer leur navigateur de manière à ne plus fournir de Referer lors de l'envoi de requêtes. Lorsqu'ils visitent normalement le site Web de la banque, le site Web considère qu'il s'agit d'une attaque CSRF car la demande n'a pas de valeur Referer et refuse l'accès aux utilisateurs légitimes.

2-Ajoutez un jeton dans l'adresse de la demande et vérifiez

La raison pour laquelle l'attaque CSRF peut réussir est que le pirate informatique peut complètement falsifier la demande de l'utilisateur, et tout les informations d'authentification de l'utilisateur 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. La clé pour résister au CSRF est d’insérer dans la demande des informations que les pirates ne peuvent pas falsifier et que ces informations n’existent pas dans les cookies. 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.

Cette méthode est 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. Ensuite, le jeton peut être retiré de la session à chaque demande et mis en correspondance avec le jeton présent. la requête. Comparez, mais la difficulté de cette méthode est de savoir comment ajouter le jeton à la requête sous forme de paramètres. Pour les requêtes GET, le jeton sera ajouté à l'adresse de la requête, de sorte que l'URL devienne http://url?csrftoken=tokenvalue. Pour les requêtes POST, ajoutez en fin de formulaire, afin que le token soit ajouté à la requête en tant que paramètre. Cependant, sur un site Web, il existe de nombreux endroits où les demandes peuvent être acceptées. Il est très difficile d'ajouter un jeton à chaque demande, et il est facile de le manquer. La méthode couramment utilisée consiste à utiliser javascript pour parcourir la page. chargé. Pour l'ensemble de l'arborescence dom, les jetons sont ajoutés après toutes les balises a et form dans le dom. Cela peut résoudre la plupart des demandes, mais pour le code HTML généré dynamiquement après le chargement de la page, cette méthode n'a aucun effet et nécessite que les programmeurs ajoutent manuellement des jetons lors du codage.

Un autre inconvénient de cette méthode est qu'il est difficile d'assurer la sécurité du token lui-même. En particulier sur certains forums et autres sites Web qui aident les utilisateurs à publier leur propre contenu, les pirates peuvent publier l'adresse de leurs propres sites Web personnels. Étant donné que le système ajoutera également un jeton après cette adresse, les pirates peuvent obtenir ce jeton sur leur propre site Web et lancer immédiatement une attaque CSRF. Afin d'éviter cela, le système peut ajouter un jugement lors de l'ajout du token. Si le lien renvoie vers le propre site Web, ajoutez le token ultérieurement. S'il mène au réseau externe, il ne sera pas ajouté. Cependant, même si le csrftoken n'est pas attaché à la requête en tant que paramètre, le site Web du pirate informatique peut toujours obtenir la valeur du jeton via le Referer pour lancer une attaque CSRF. C'est également pourquoi certains utilisateurs aiment désactiver manuellement la fonction Referer du navigateur.

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

Cette méthode utilise également un jeton et une vérification. Différente de la méthode précédente, il n'y a pas de place pour mettre le jeton. en tant que paramètre dans la requête HTTP, placez-le 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 du 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.

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, pour utiliser cette méthode de protection, toutes les requêtes doivent être modifiées en requêtes XMLHttpRequest, ce qui réécrira presque l'intégralité du site Web. Ce coût est sans aucun doute inacceptable

Attaque 4-CC

4-1 Principe de l'attaque CC :

Le principe du CC L'attaque est que l'attaquant contrôle certains hôtes pour envoyer en continu un grand nombre de paquets de données à l'autre serveur, provoquant l'épuisement des ressources du serveur, jusqu'à ce qu'il plante. CC est principalement utilisé pour consommer les ressources du serveur. Tout le monde a cette expérience : lorsque de nombreuses personnes visitent une page Web, l'ouverture de la page Web sera lente simulant plusieurs utilisateurs (autant de threads sont autant d'utilisateurs) sans s'arrêter. qui nécessitent une grande quantité d'opérations de données (c'est-à-dire nécessitent beaucoup de temps CPU) entraînent un gaspillage des ressources du serveur. Le CPU reste longtemps à 100 % et il y a toujours des connexions inachevées jusqu'à ce que le réseau soit encombré et normal. l'accès est suspendu.

4-2 Types d'attaques CC :

Il existe trois types d'attaques CC,

Directes attaque
• Attaque par proxy
• Attaque de botnet

L'attaque directe cible principalement les applications WEB présentant des défauts importants. De manière générale, elle survient lorsqu'il y a un problème d'écriture de. le programme. Cette situation se produit relativement rarement. Les attaques par botnet sont quelque peu similaires aux attaques DDOS. Elles ne peuvent pas être défendues au niveau des applications WEB, les attaques par proxy sont donc des attaquants CC. Généralement, les attaquants exploiteront un lot de serveurs proxy, tels que 100 proxys, puis chaque proxy émettra 10 requêtes. en même temps. , de sorte que le serveur WEB reçoive 1 000 requêtes simultanées en même temps et se déconnecte immédiatement du proxy après l'envoi de la requête, pour éviter que les données renvoyées par le proxy ne bloquent sa propre bande passante et ne puissent lancer une autre requête. . A ce moment, le serveur WEB va Les processus qui répondent à ces requêtes sont mis en file d'attente, et il en va de même pour le serveur de base de données. De cette façon, les requêtes normales seront traitées à la fin, tout comme lorsque vous vous rendez à la cantine. pour manger, il y a généralement moins de dix personnes dans la file. Aujourd'hui, si mille personnes sont insérées devant vous, alors la chance que ce soit votre tour est très faible. À ce moment-là, la page s'ouvrira extrêmement lentement ou un peu plus tard. un écran blanc apparaîtra.

4-3 La différence entre les attaques CC et les DDOS

DDoS est une attaque sur IP, tandis que CC attaque les ressources du serveur.

Attaque 5-DOS

DOS : Le nom chinois est un déni de service. Toutes les attaques pouvant provoquer un comportement DOS sont appelées attaques DOS. L'effet de cette attaque est de rendre l'ordinateur ou le réseau incapable de fournir des services normaux. Les attaques DOS courantes incluent les attaques contre la bande passante et la connectivité du réseau informatique. DOS est une attaque autonome entre ordinateurs autonomes.

Le principe de l'attaque DOS : dans un premier temps, l'attaquant envoie un grand nombre de fausses requêtes IP au serveur attaqué. Le serveur attaqué renvoie les informations de confirmation après avoir reçu la requête et attend que l'attaquant confirme (HTTP est. requise ici. Connaissance de base du fonctionnement du protocole et de la prise de contact à trois voies TCP. Ce processus nécessite une prise de contact à trois voies de TCP. Étant donné que les informations de demande envoyées par l'attaquant sont fausses, le serveur ne peut pas recevoir les informations de confirmation renvoyées et le serveur le recevra. être en état d'attente pendant un certain temps, mais les ressources allouées à cette demande n'ont pas été libérées. Lorsque l'attaquant attend pendant un certain temps, la connexion sera déconnectée en raison d'un délai d'attente. À ce moment-là, l'attaquant enverra à nouveau une nouvelle fausse demande d'informations, de sorte qu'à terme, les ressources du serveur seront épuisées jusqu'à ce qu'il soit paralysé.

Attaque 6-DDOS

L'attaque DDoS est une méthode d'attaque par déni de service distribuée basée sur une attaque DoS traditionnelle. méthode d'attaque produite. Une attaque DoS unique est généralement menée de manière individuelle. Avec le développement de la technologie informatique et réseau, la difficulté des attaques DoS a augmenté. C'est ainsi qu'est née l'attaque DDoS. Son principe est très simple : la puissance de traitement des ordinateurs et des réseaux a été multipliée par 10. Attaquer avec une seule machine d'attaque ne fonctionne plus. Ensuite, le DDoS est lancé en utilisant davantage de machines fantoches. à une plus grande échelle qu'auparavant. Les logiciels DDoS couramment utilisés incluent : LOIC.

Je voudrais ajouter deux points ici : premièrement, les attaques DDOS peuvent non seulement attaquer les ordinateurs, mais également les routeurs, car les routeurs sont un type spécial d'ordinateur ; deuxièmement, la vitesse du réseau détermine la qualité et la rapidité de l'attaque. , si Dans un environnement où la vitesse de votre réseau est limitée, leur effet d'attaque n'est pas très évident, mais une vitesse de réseau rapide est plus efficace.

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!