Explication détaillée de la façon d'empêcher l'injection SQL en PHP

Cet article présente principalement comment empêcher l'injection SQL en PHP. Il a une très bonne valeur de référence, jetons-y un coup d'œil avec l'éditeur ci-dessous

1 Qu'est-ce qu'une attaque par injection SQL ?

L'attaque dite par injection SQL signifie que l'attaquant insère une commande SQL Saisissez le champ de saisie d'un formulaire Web ou la chaîne de requête d'une requête de page pour inciter le serveur à exécuter des commandes SQL malveillantes. Dans certains formulaires, le contenu saisi par l'utilisateur est directement utilisé pour construire (ou affecter) des commandes SQL dynamiques, ou est utilisé comme paramètres d'entrée pour des procédures stockées. De tels formulaires sont particulièrement vulnérables aux attaques par injection SQL. Les processus d'attaque par injection SQL courants sont les suivants :

⑴ Une application Web ASP.NET possède une page de connexion. Cette page de connexion contrôle si l'utilisateur est autorisé à accéder à l'application. Elle nécessite que l'utilisateur entre un nom et. mot de passe.

⑵ Le contenu saisi sur la page de connexion sera directement utilisé pour construire des commandes SQL dynamiques, ou directement utilisé comme paramètres de procédures stockées. Voici un exemple d'application ASP.NET construisant une requête :

 System.Text.StringBuilder query = new System.Text.StringBuilder("SELECT * from Users WHERE login = '")。Append(txtLogin.Text)。Append("' AND password='")。Append(txtPassword.Text)。Append("'");

⑶ L'attaquant saisit "' ou '1 dans le nom d'utilisateur et zones de saisie du mot de passe '='1" et autres.

⑷ Une fois le contenu saisi par l'utilisateur soumis au serveur, le serveur exécute le code ASP.NET ci-dessus pour construire une commande SQL pour interroger l'utilisateur. Cependant, parce que le contenu saisi par l'attaquant est très. spécial, la commande SQL finale devient ：SELECT * from Users WHERE login = '' ou '1'='1' AND password = '' ou '1'='1'.

⑸ Le serveur exécute le requête ou procédure stockée et convertit l'entrée utilisateur. Comparez les informations d'identité avec les informations d'identité stockées sur le serveur.

⑹ La commande SQL ayant effectivement été modifiée par une attaque par injection, l'identité de l'utilisateur ne peut pas être véritablement vérifiée, le système autorisera donc l'attaquant de manière incorrecte.

Si un attaquant sait que l'application utilisera directement le contenu saisi dans le formulaire pour des requêtes de vérification d'identité, il tentera de saisir des chaînes SQL spéciales pour falsifier la requête afin de modifier sa fonctionnalité d'origine et tromper le système. en accordant des autorisations.

Selon l'environnement du système, les dommages qu'un attaquant peut causer sont également différents, qui sont principalement déterminés par les autorisations de sécurité de l'application pour accéder à la base de données. Si le compte de l'utilisateur dispose de droits d'administrateur ou d'autres droits relativement avancés, l'attaquant peut effectuer diverses opérations sur les tables de la base de données qu'il souhaite effectuer, notamment l'ajout, la suppression ou la mise à jour de données, voire la suppression directe de la table.

2. Comment l'empêcher ?

Heureusement, il n'est pas particulièrement difficile d'empêcher les applications ASP.NET d'être envahies par des attaques par injection SQL tant que vous utilisez le contenu saisi dans le fichier. formulaire pour construire SQL Avant d'émettre la commande, filtrez simplement tout le contenu d'entrée. Le filtrage des entrées peut être effectué de différentes manières.

(1) Pour construire dynamiquement des requêtes SQL, vous pouvez utiliser la technologie suivante :

Premièrement : remplacer les guillemets simples, c'est-à-dire changer tous les guillemets simples en deux guillemets simples, pour empêcher les attaquants de modifier la signification des commandes SQL. En regardant à nouveau l'exemple précédent, "SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'" obtiendra évidemment le même "SELECT * from Users WHERE login = '' ou '1'='1' AND password = '' ou '1'='1'" des résultats différents.

Deuxièmement : supprimez tous les traits d'union dans les entrées utilisateur pour empêcher les attaquants de construire des requêtes telles que "SELECT * from Users WHERE login = 'mas' —— AND password =''". Parce que la seconde moitié de ce type de La requête a été commentée et n'est plus valide, l'attaquant a seulement besoin de connaître un nom de connexion d'utilisateur légitime et n'a pas besoin de connaître le mot de passe de l'utilisateur pour réussir à accéder.

Troisième : Limitez les autorisations du compte de base de données utilisé pour exécuter les requêtes. Utilisez différents comptes d'utilisateurs pour effectuer des opérations de requête, d'insertion, de mise à jour et de suppression. En isolant les opérations pouvant être effectuées par différents comptes, il évite que l'endroit initialement utilisé pour exécuter la commande SELECT soit utilisé pour exécuter la commande INSERT, UPDATE ou DELETE.

(2) Utilisez des procédures stockées pour exécuter toutes les requêtes. La manière dont les paramètres SQL sont transmis empêchera les attaquants d'utiliser des guillemets simples et des traits d'union pour mener des attaques. En outre, il permet également de restreindre les autorisations de la base de données pour autoriser uniquement l'exécution de procédures stockées spécifiques. Toutes les entrées utilisateur doivent être conformes au contexte de sécurité de la procédure stockée appelée, de sorte que les attaques par injection soient difficiles à produire.

(3) Limiter la longueur de la saisie du formulaire ou de la chaîne de requête. Si le nom de connexion de l'utilisateur ne comporte qu'un maximum de 10 caractères, n'acceptez pas plus de 10 caractères saisis dans le formulaire. Cela augmentera considérablement la difficulté pour les attaquants d'insérer du code nuisible dans les commandes SQL.

(4) Vérifiez la légalité de la saisie de l'utilisateur et assurez-vous que le contenu saisi ne contient que des données légales. L'inspection des données doit être effectuée à la fois côté client et côté serveur - la validation côté serveur est effectuée pour compenser la sécurité fragile du mécanisme de validation côté client.

Côté client, il est tout à fait possible pour un attaquant d'obtenir le code source de la page web, de modifier le script qui vérifie la légalité (ou de supprimer directement le script), puis de soumettre le contenu illégal au serveur via le forme modifiée. Par conséquent, la seule façon de garantir que l’opération de vérification a réellement été effectuée est d’effectuer également une vérification côté serveur. Vous pouvez utiliser de nombreux objets de validation intégrés, tels que RegularExpressionValidator, qui peuvent générer automatiquement des scripts côté client pour la validation, et bien sûr, vous pouvez également insérer des appels de méthode côté serveur. Si vous ne trouvez pas d'objet de validation prêt à l'emploi, vous pouvez en créer un vous-même via CustomValidator.

(5) Cryptez et enregistrez le nom de connexion, le mot de passe et d'autres données de l'utilisateur. Chiffrer les données saisies par l'utilisateur puis les comparer avec les données enregistrées dans la base de données équivaut à « stériliser » les données saisies par l'utilisateur. Les données saisies par l'utilisateur n'ont plus de signification particulière pour la base de données, cela empêche donc. les attaquants d'injecter des commandes SQL. La classe System.Web.Security.FormsAuthentication possède un HashPasswordForStoringInConfigFile, qui est très approprié pour nettoyer les données d'entrée.

(6) Vérifiez le nombre d'enregistrements renvoyés par la requête pour extraire les données. Si le programme exige qu'un seul enregistrement soit renvoyé, mais que l'enregistrement effectivement renvoyé comporte plusieurs lignes, il sera traité comme une erreur.

(7) Utilisez des instructions préparées

Pour des explications plus détaillées sur les méthodes PHP pour empêcher l'injection SQL et les articles associés, veuillez faire attention au site Web PHP chinois !