Cet article partage principalement avec vous plusieurs méthodes d'attaque courantes pour résoudre le développement de sites Web PHP. Les menaces de sécurité courantes dans la construction de sites Web PHP incluent : l'injection SQL, la manipulation des variables GET et POST, les attaques par débordement de tampon, les attaques de scripts intersites, les données du navigateur. manipulation et soumission de formulaires à distance.
Dans les attaques par injection SQL, les utilisateurs ajoutent des informations aux requêtes de base de données en manipulant des formulaires ou des chaînes de requête GET.
Par exemple, imaginez une simple base de données de connexion. Chaque enregistrement de cette base de données comporte un champ de nom d'utilisateur et un champ de mot de passe. Créez un formulaire de connexion pour permettre aux utilisateurs de se connecter.
La solution à ce problème consiste à utiliser la fonction mysql_real_escape_string() intégrée de PHP comme enveloppe autour de toute entrée utilisateur.
Cette fonction échappe les caractères d'une chaîne, ce qui rend impossible la transmission de caractères spéciaux tels que les apostrophes et permet à MySQL de fonctionner en fonction des caractères spéciaux. Le listing 7 montre le code échappé.
Ce n'est pas parce qu'un utilisateur dispose d'un mot de passe valide qu'il agira conformément aux règles - il a de nombreuses occasions de causer des dommages. Par exemple, une application peut permettre aux utilisateurs de visualiser un contenu spécial.
Par exemple template.php?pid=33 ou template.php?pid=321. La partie de l'URL située après le point d'interrogation est appelée chaîne de requête. Étant donné que la chaîne de requête est placée directement dans l’URL, elle est également appelée chaîne de requête GET.
Y a-t-il quelque chose qui ne va pas ici ?
Premièrement, il existe une croyance implicite selon laquelle la variable GET pid du navigateur est sûre.
Que va-t-il se passer ?
La plupart des utilisateurs ne sont pas assez intelligents pour construire des attaques sémantiques. Cependant, s'ils remarquent pid=33 dans le champ d'emplacement de l'URL du navigateur, ils pourraient commencer à causer des problèmes.
S'ils saisissent un autre numéro, alors c'est probablement bien ; mais s'ils saisissent autre chose, comme une commande SQL ou le nom d'un fichier (comme /etc/passwd), ou un autre problème comme Entrez une valeur jusqu'à 3 000 caractères, et que se passe-t-il ?
Dans ce cas, rappelez-vous la règle de base : ne faites pas confiance aux entrées des utilisateurs.
Les développeurs d'applications savent que les identifiants personnels (PID) acceptés par template.php doivent être numériques, ils peuvent donc utiliser la fonction is_numeric() de PHP pour garantir que les PID non numériques ne sont pas acceptés.
Tout ce que vous avez à faire est d'utiliser strlen() pour vérifier si la longueur de la variable est différente de zéro ; si c'est le cas, utilisez une expression régulière entièrement numérique pour vous assurer que l'élément de données est valide. Si le PID contient des lettres, des barres obliques, des points ou tout ce qui ressemble à de l'hexadécimal, cette routine le capture et bloque la page de l'activité de l'utilisateur.
L'attaque par débordement de tampon tente de provoquer un débordement de tampon d'allocation de mémoire dans l'application PHP (ou plus précisément, dans Apache ou le système d'exploitation sous-jacent). s'est produit.
N'oubliez pas que vous écrivez peut-être votre application Web dans un langage de haut niveau comme PHP, mais vous finissez quand même par appeler C (dans le cas d'Apache). Comme la plupart des langages de bas niveau, le C applique des règles strictes en matière d’allocation de mémoire.
Les attaques par débordement de tampon envoient une grande quantité de données au tampon, provoquant le débordement d'une partie des données dans des tampons de mémoire adjacents, détruisant ainsi le tampon ou réécrivant la logique. Cela peut provoquer un déni de service, corrompre les données ou exécuter du code malveillant sur le serveur distant.
La seule façon d'empêcher les attaques par débordement de tampon est de vérifier la longueur de toutes les entrées utilisateur.
Notez que les attaques par débordement de tampon ne se limitent pas aux longues chaînes de chiffres ou de lettres. Vous pouvez également voir de longues chaînes hexadécimales (ressemblant souvent à xA3 ou xFF).
N'oubliez pas que le but de toute attaque par débordement de tampon est d'inonder un tampon spécifique et de placer du code ou des instructions malveillants dans le tampon suivant, corrompant ainsi les données ou exécutant du code malveillant.
Le moyen le plus simple de gérer le dépassement de tampon hexadécimal est de ne pas autoriser l'entrée à dépasser une certaine longueur.
Si vous avez affaire à une zone de texte de formulaire qui permet des entrées plus longues dans la base de données, il n'existe aucun moyen de limiter facilement la longueur des données côté client. Une fois que les données atteignent PHP, vous pouvez utiliser des expressions régulières pour effacer toutes les chaînes de type hexadécimal.
Dans une attaque de script intersite (XSS), un utilisateur malveillant saisit souvent des informations dans un formulaire (ou via d'autres méthodes de saisie utilisateur), et celles-ci Les entrées seront insérées dans des processus ou des bases de données. Des jetons malveillants côté client seront insérés.
Par exemple, disons que vous disposez d'un simple programme de livre d'or sur votre site qui permet aux visiteurs de laisser leur nom, leur adresse e-mail et un bref message.
Un utilisateur malveillant pourrait profiter de cette opportunité pour insérer autre chose qu'un bref message, comme une image inappropriée pour les autres utilisateurs ou du JavaScript qui redirige l'utilisateur vers un autre site, ou vole des informations sur les cookies.
Heureusement, PHP fournit la fonction strip_tags(), qui permet de supprimer tout contenu entouré de balises HTML. La fonction strip_tags() permet également de fournir une liste de balises autorisées.
L'utilisation de strip_tags() pour la saisie des utilisateurs publics est nécessaire du point de vue de la sécurité. Si le formulaire se trouve dans une zone protégée (comme un système de gestion de contenu) et que vous faites confiance aux utilisateurs pour effectuer leurs tâches correctement (comme créer du contenu HTML pour un site Web), l'utilisation de strip_tags() peut être inutile et affecter la productivité.
Il y a une autre question : si vous souhaitez accepter les entrées des utilisateurs, telles que les commentaires sur les publications ou les éléments d'inscription des invités, et que vous devez afficher ces entrées à d'autres utilisateurs, vous devez alors mettre la réponse dans le fichier htmlspecialchars() de PHP. en fonction.
Cette fonction convertit les symboles esperluette, < et > Par exemple, l'esperluette (&) devient &. Dans ce cas, même si le contenu malveillant échappe au traitement de strip_tags() en front-end, il sera traité par htmlspecialchars() en back-end.
Il existe un type de plug-in de navigateur qui permet aux utilisateurs de falsifier les éléments d'en-tête et de formulaire sur la page. Grâce à Tamper Data, un plug-in de Mozilla, il est facile de manipuler des formulaires simples comportant de nombreux champs de texte masqués pour envoyer des instructions à PHP et MySQL.
Avant que l'utilisateur clique sur Soumettre sur le formulaire, il peut démarrer Tamper Data. Lors de la soumission du formulaire, il verra une liste des champs de données du formulaire.
Tamper Data permet à l'utilisateur de falsifier ces données avant que le navigateur ne termine la soumission du formulaire.
Le moyen le plus simple de se défendre contre cet outil est de supposer que n'importe quel utilisateur pourrait utiliser Tamper Data (ou un outil similaire).
Fournissez uniquement la quantité minimale d'informations dont le système a besoin pour traiter le formulaire et soumettez le formulaire à une logique dédiée. Par exemple, le formulaire d'inscription ne doit être soumis qu'à la logique d'inscription.
Et si vous avez construit une fonction de traitement de formulaire commune et que de nombreuses pages utilisent cette logique commune ?
Et si vous utilisiez des variables cachées pour contrôler le flux ?
Par exemple, il peut être spécifié dans une variable de formulaire caché dans quelle table de base de données écrire ou quel référentiel de fichiers utiliser. Il y a 4 options :
Ne changez rien et priez pour qu'il n'y ait pas d'utilisateurs malveillants sur le système.
Réécrivez la fonction pour utiliser une fonction de traitement de formulaire dédiée plus sûre et évitez d'utiliser des variables de formulaire cachées.
Utilisez md5() ou d'autres mécanismes de cryptage pour crypter les noms de tables ou d'autres informations sensibles dans des variables de formulaire masquées. N'oubliez pas de les décrypter côté PHP.
Obscurcissez la signification des valeurs en utilisant des abréviations ou des surnoms, puis convertissez ces valeurs en fonctions de traitement de formulaire PHP. Par exemple, si vous souhaitez référencer la table des utilisateurs, vous pouvez la référencer avec u ou n'importe quelle chaîne (telle que u8y90×0jkL).
Ces deux dernières options ne sont pas parfaites, mais elles sont bien meilleures que de laisser l'utilisateur deviner facilement la logique du middleware ou le modèle de données.
L'avantage du Web est qu'il permet de partager des informations et des services. L’inconvénient est le partage d’informations et de services car certains font les choses sans aucun scrupule.
Prenons un formulaire comme exemple. N'importe qui peut visiter un site Web et créer une copie locale du formulaire en utilisant Fichier > Enregistrer sous sur le navigateur. Il peut alors modifier le paramètre action pour pointer vers une URL pleinement qualifiée (non pas vers formHandler.php, mais vers http://www.votresite.com/formHandler.php puisque le formulaire est sur ce site) et faire ce qu'il veut. toute modification, cliquez sur Soumettre et le serveur recevra les données de ce formulaire sous forme de flux de communication légal.
Tout d'abord, vous pouvez envisager de vérifier $_SERVER['HTTP_REFERER'] pour déterminer si la requête provient de votre propre serveur. Cette méthode peut bloquer la plupart des utilisateurs malveillants, mais elle ne peut pas bloquer les pirates les plus sophistiqués. Ces personnes sont suffisamment intelligentes pour falsifier les informations de référence dans l'en-tête afin de donner l'impression que la copie distante du formulaire a été soumise depuis votre serveur.
Une meilleure façon de gérer la soumission de formulaire à distance consiste à générer un jeton basé sur une chaîne ou un horodatage unique et à placer ce jeton dans la variable de session et le formulaire. Après avoir soumis le formulaire, vérifiez si les deux jetons correspondent. Si cela ne correspond pas, vous savez que quelqu'un essaie d'envoyer des données à partir d'une copie distante du formulaire.
Utilisez mysql_real_escape_string() pour éviter les problèmes d'injection SQL.
Utilisez des expressions régulières et strlen() pour vous assurer que les données GET n'ont pas été falsifiées.
Utilisez des expressions régulières et strlen() pour garantir que les données soumises par l'utilisateur ne dépassent pas les tampons de mémoire.
Utilisez strip_tags() et htmlspecialchars() pour empêcher les utilisateurs de soumettre des balises HTML potentiellement dangereuses.
Empêchez le système d'être violé par des outils tels que Tamper Data.
Utilisez un jeton unique pour empêcher les utilisateurs de soumettre des formulaires au serveur à distance.
Recommandations associées :
Comment prévenir attaques Web- -Problèmes de sécurité que les débutants PHP doivent connaître
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!