Comment empêcher les attaques par injection SQL dans ASP.NET

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

L'attaque par injection SQL se produit lorsqu'un attaquant insère des commandes SQL dans le champ de saisie d'un formulaire Web ou dans la chaîne de requête d'une requête de page, incitant le serveur à exécuter des commandes SQL malveillantes. Dans certains formulaires, les entrées utilisateur sont utilisées directement pour construire (ou affecter) des commandes SQL dynamiques, ou 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'='1" dans le nom d'utilisateur et le mot de passe. zones de saisie.

　⑷ 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 une requête ou une procédure stockée pour comparer les informations d'identité saisies par l'utilisateur avec les informations d'identité enregistrées sur le serveur.

　⑹ Étant donné que la commande SQL a 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 de manière incorrecte l'attaquant.

Si un attaquant sait que l'application utilisera le contenu saisi dans le formulaire directement 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 le prévenir ?

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

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

Première : Remplacer les guillemets simples, c'est-à-dire changer tous les guillemets simples qui apparaissent seuls en deux guillemets simples pour empêcher l'attaquant modifie 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 créer 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 : restreindre 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.

⑵ 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.　　

⑶ 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 que 10 caractères au maximum, 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.

⑷ 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.

La vérification 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.​ ​

⑸ Cryptez et enregistrez le nom de connexion, le mot de passe et d'autres données de l'utilisateur.

Crypter les données saisies par l'utilisateur puis les comparer avec les données enregistrées dans la base de données. Cela équivaut à "stériliser" les données saisies par l'utilisateur. Les données saisies par l'utilisateur n'ont plus de particularité. effet sur la base de données, empêchant ainsi 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.　　

⑹ Vérifiez le nombre d'enregistrements renvoyés par la requête qui extrait les données.

Si le programme ne demande de renvoyer qu'un seul enregistrement, mais que l'enregistrement effectivement renvoyé comporte plusieurs lignes, il sera traité comme une erreur.

Ce qui précède explique comment ASP.NET empêche les attaques par injection SQL. J'espère que cela sera utile à l'apprentissage de chacun.

Pour plus d'articles sur la façon dont ASP.NET peut empêcher les attaques par injection SQL, veuillez prêter attention au site Web PHP chinois !