Comment empêcher l'injection SQL dans MySQL

Méthode MySQL pour empêcher l'injection SQL : 1. Les autorisations des utilisateurs ordinaires et des utilisateurs administrateurs système doivent être strictement séparées ; 2. Forcer les utilisateurs à utiliser des instructions paramétrées ; Base de données SQL Server 4. Vérifiez le contenu saisi par l'utilisateur.

Les attaques par injection SQL sont très dangereuses. Les attaquants peuvent l'utiliser pour lire, modifier ou supprimer des données dans la base de données, et obtenir des noms d'utilisateur et des mots de passe dans la base de données. et d'autres informations sensibles, et peut même obtenir les autorisations de l'administrateur de la base de données. Si vous pouvez réutiliser des procédures stockées étendues SQL Server et des procédures stockées étendues personnalisées pour exécuter certaines commandes système, l'attaquant peut également prendre le contrôle du système.

(Tutoriel recommandé : Tutoriel vidéo MySQL)

Et l'injection SQL est également difficile à empêcher. Les administrateurs de sites Web ne peuvent pas se protéger en installant des correctifs système ou en effectuant de simples configurations de sécurité, et les pare-feu généraux ne peuvent pas bloquer les attaques par injection SQL.

Comment MySQL empêche-t-il l'injection SQL ?

1 Il doit y avoir une distinction stricte entre les autorisations des utilisateurs ordinaires et des utilisateurs administrateurs système.

Si un utilisateur ordinaire intègre une autre instruction Drop Table dans une instruction de requête, son exécution est-elle autorisée

Puisque l'instruction Drop est liée aux objets de base de la base de données, elle doit être exploitée. L'utilisateur de cette instruction doit disposer des autorisations appropriées. Dans la conception des autorisations, pour les utilisateurs finaux, c'est-à-dire les utilisateurs de logiciels d'application, il n'est pas nécessaire de leur accorder des autorisations pour créer et supprimer des objets de base de données.

Ainsi, même s'il y a du code malveillant intégré dans les instructions SQL qu'ils utilisent, ces codes ne seront pas exécutés en raison des restrictions sur leurs autorisations utilisateur.

2. Forcer l'utilisation d'instructions paramétrées.

Si lors de l'écriture d'une instruction SQL, les variables saisies par l'utilisateur ne sont pas directement intégrées dans l'instruction SQL. Si vous transmettez cette variable via des paramètres, vous pouvez empêcher efficacement les attaques par injection SQL.

En d’autres termes, les entrées de l’utilisateur ne doivent pas être directement intégrées dans les instructions SQL. En revanche, les entrées utilisateur doivent être filtrées ou des instructions paramétrées doivent être utilisées pour transmettre les variables d'entrée utilisateur. Les instructions paramétrées utilisent des paramètres au lieu d'incorporer des variables d'entrée utilisateur dans l'instruction SQL. Grâce à cette mesure,

peut éliminer la plupart des attaques par injection SQL. Malheureusement, peu de moteurs de bases de données prennent en charge les instructions paramétrées. Cependant, les ingénieurs de bases de données doivent essayer d'utiliser des instructions paramétrées lors du développement de produits.

3. Utilisez les paramètres de sécurité fournis avec la base de données SQL Server.

Afin de réduire les effets néfastes des attaques par injection sur la base de données SQL Server, des paramètres SQL relativement sûrs sont spécialement conçus dans la base de données SQL Server. Au cours du processus de conception de la base de données, les ingénieurs doivent essayer d'utiliser ces paramètres pour empêcher les attaques malveillantes par injection SQL.

Par exemple, la collection Parameters est fournie dans la base de données SQL Server. Cette collection fournit des fonctionnalités de vérification de type et de validation de longueur. Si l'administrateur utilise la collection Parameters, les entrées de l'utilisateur seront traitées comme des valeurs de caractères plutôt que comme du code exécutable. Même si le contenu saisi par l'utilisateur contient du code exécutable, la base de données le filtrera. Parce qu'à l'heure actuelle, la base de données ne le traite que comme un caractère ordinaire. Un autre avantage de l'utilisation de la collection Parameters est que des vérifications de type et de longueur peuvent être appliquées et que les valeurs en dehors de la plage déclencheront une exception.

Si la valeur saisie par l'utilisateur n'est pas conforme aux contraintes de type et de longueur spécifiées, une exception se produira et sera signalée à l'administrateur. Par exemple, dans le cas ci-dessus, si le type de données défini par le numéro d'employé est de type chaîne, la longueur est de 10 caractères. Bien que le contenu saisi par l'utilisateur soit également des données de type caractère, sa longueur atteint 20 caractères. Une exception sera levée à ce moment car la longueur de l'entrée utilisateur dépasse la limite de longueur du champ de la base de données.

4. Renforcer la vérification des entrées des utilisateurs.

En général, deux méthodes peuvent être utilisées pour empêcher les attaques par injection SQL

L'une consiste à renforcer l'inspection et la vérification du contenu saisi par l'utilisateur ; instructions paramétrées. Transmettre l’entrée de l’utilisateur.

Dans la base de données SQLServer, il existe de nombreux outils de vérification du contenu des entrées utilisateur qui peuvent aider les administrateurs à faire face aux attaques par injection SQL. Testez le contenu d'une variable chaîne et acceptez uniquement la valeur requise. Rejetez les entrées contenant des données binaires, des séquences d'échappement et des caractères de commentaire. Cela permet d'empêcher l'injection de scripts et empêche certaines attaques par débordement de tampon. Testez les entrées utilisateur pour la taille et le type de données, en appliquant les limites et les conversions appropriées. Cela permet d’éviter les débordements intentionnels de tampon et a un effet significatif sur la prévention des attaques par injection.

Par exemple, vous pouvez utiliser des procédures stockées pour vérifier les entrées de l'utilisateur. Vous pouvez utiliser des procédures stockées pour filtrer les variables d'entrée utilisateur, par exemple en rejetant certains symboles spéciaux. Par exemple, dans le code malveillant ci-dessus, tant que la procédure stockée filtre le point-virgule, le code malveillant sera inutile.

Avant d'exécuter l'instruction SQL, vous pouvez utiliser la procédure stockée de la base de données pour rejeter certains symboles spéciaux. Sans affecter l'application de la base de données, la base de données doit être autorisée à rejeter les entrées contenant les caractères suivants. Comme le délimiteur point-virgule, qui est le principal complice des attaques par injection SQL. Tel que le séparateur de commentaires. Les annotations ne sont utilisées que lors de la conception des données. Généralement, il n'y a pas de contenu de commentaire nécessaire dans l'instruction de requête de l'utilisateur, il peut donc être rejeté directement dans des circonstances normales, cela n'entraînera pas de pertes inattendues. Si ces symboles spéciaux sont rejetés, même si du code malveillant est intégré dans l'instruction SQL, ils ne feront rien.

Vérifiez donc toujours les entrées de l'utilisateur et filtrez les entrées de l'utilisateur en testant le type, la longueur, le format et la plage. Il s'agit d'une mesure courante et efficace pour prévenir les attaques par injection SQL.

Comment prévenir les attaques par injection SQL dans un environnement multicouche ?

Dans un environnement d'application à plusieurs niveaux, toutes les données saisies par les utilisateurs doivent être vérifiées avant d'être autorisées à accéder à la zone de confiance.

Les données qui échouent au processus de validation doivent être rejetées par la base de données et un message d'erreur renvoyé à la couche supérieure. Implémentez une vérification multicouche. Les précautions prises contre les utilisateurs malveillants inutiles peuvent ne pas être efficaces contre des attaquants déterminés.

Une meilleure pratique consiste à valider les entrées au niveau de l'interface utilisateur et à tous les points ultérieurs au-delà des limites de confiance. Par exemple, la validation des données dans l'application client peut empêcher une simple injection de script.

Cependant, si la couche suivante pense que son entrée a été validée, tout utilisateur malveillant pouvant contourner le client peut avoir un accès illimité au système. Par conséquent, pour les environnements d'applications multicouches, lors de la prévention des attaques par injection, toutes les couches doivent fonctionner ensemble et des mesures correspondantes doivent être prises du côté client et de la base de données pour empêcher les attaques par injection d'instructions SQL.

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!