Tutoriel de test d’injection SQL (exemple et prévention des attaques par injection SQL)

Exemples d’injection SQL et moyens d’empêcher les attaques par injection SQL sur les applications Web

Lors du test d’un site Web ou d’un système, l’objectif du testeur est de s’assurer que le produit testé est autant que possible protégé.

Des tests de sécurité sont généralement effectués à cette fin. Afin d’effectuer ce type de test, nous devons d’abord considérer quelles attaques sont les plus susceptibles de se produire. L’injection SQL est l’une de ces attaques.

L’injection SQL est considérée comme l’une des attaques les plus courantes car elle peut entraîner des conséquences graves et néfastes pour votre système et vos données sensibles.

Qu’est-ce que l’injection SQL ?

Certaines des entrées utilisateur peuvent être utilisées pour encadrer des instructions SQL qui sont ensuite exécutées par l’application sur la base de données. Il est possible qu’une application ne gère PAS correctement les entrées fournies par l’utilisateur.

Si tel est le cas, un utilisateur malveillant pourrait fournir des entrées inattendues à l’application qui sont ensuite utilisées pour encadrer et exécuter des instructions SQL sur la base de données. C’est ce qu’on appelle l’injection SQL. Les conséquences d’une telle action pourraient être alarmantes.

Comme son nom l’indique, le but de l‘attaque par injection SQL est d’injecter le code SQL malveillant.

Chaque champ d’un site Web est comme une porte d’accès à la base de données. Dans le formulaire de connexion, l’utilisateur saisit les données de connexion, dans le champ de recherche, l’utilisateur saisit un texte de recherche, dans le formulaire d’enregistrement des données, l’utilisateur saisit les données à enregistrer. Toutes ces données indiquées vont à la base de données.

Au lieu de données correctes, si un code malveillant est entré, il est possible que de graves dommages se produisent à la base de données et à l’ensemble du système.

L’injection SQL est effectuée avec le langage de programmation SQL. SQL (Structured Query Language) est utilisé pour gérer les données contenues dans la base de données. Par conséquent, lors de cette attaque, ce code de langage de programmation est utilisé comme une injection malveillante.

C’est l’une des attaques les plus populaires, car les bases de données sont utilisées pour presque toutes les technologies.

De nombreuses applications utilisent un certain type de base de données. Une application testée peut avoir une interface utilisateur qui accepte les entrées utilisateur qui est utilisée pour effectuer les tâches suivantes :

#1) Afficher les données stockées pertinentes à l’utilisateur, par exemple l’application vérifie les informations d’identification de l’utilisateur à l’aide des informations de connexion saisies par l’utilisateur et expose uniquement les fonctionnalités et données pertinentes à l’utilisateur.

#2) Enregistrez les données saisies par l’utilisateur dans la base de données. Par exemple, une fois que l’utilisateur a rempli un formulaire et l’a soumis, l’application procède à l’enregistrement des données dans la base de données ; ces données sont ensuite mises à disposition de l’utilisateur dans la même session ainsi que dans les sessions suivantes.

Outils recommandés

#1) Acunetix

Acunetix est un scanner de sécurité d’applications Web doté de capacités de gestion de la sécurité de tous les actifs Web. Il peut détecter plus de 7000 vulnérabilités, y compris l’injection SQL. Il utilise une technologie avancée d’enregistrement de macros qui vous permet de numériser des formulaires complexes à plusieurs niveaux ainsi que des zones protégées par mot de passe du site.

Il n’y aura pas de longs temps d’installation et d’intégration. L’outil est intuitif et facile à utiliser. La numérisation sera effectuée à une vitesse fulgurante. Il aide à automatiser la sécurité grâce à des fonctionnalités telles que la planification et la hiérarchisation des analyses, l’analyse automatique des nouvelles versions, etc.

#2) Netsparker

allumeur de filet propose le SQL Injection Vulnerability Scanner qui possède des fonctionnalités de détection automatique de toutes les variantes de la vulnérabilité d’injection comme aveugle, hors limite et intrabande, etc.

Il utilise la technologie Proof-Based Scanning™. Il offre des fonctionnalités pour les tests d’intrusion, les inclusions de fichiers à distance, la vérification des serveurs Web pour les erreurs de configuration, les scripts intersites, etc. Netsparker peut être intégré de manière transparente à vos systèmes actuels.

Risques de l’injection SQL

De nos jours, une base de données est utilisée pour presque tous les systèmes et sites Web, car les données doivent être stockées quelque part.

Comme des données sensibles sont stockées dans la base de données, il y a plus de risques impliqués dans la sécurité du système. Si les données d’un site Web ou d’un blog personnel étaient volées, il n’y aurait pas beaucoup de dommages par rapport aux données qui seraient volées du système bancaire.

Le but principal de cette attaque est de pirater la base de données du système, donc les conséquences de cette attaque peuvent vraiment être néfastes.

Les choses suivantes peuvent résulter de l’injection SQL

• Piratage du compte d’une autre personne.
• Voler et copier les données sensibles du site Web ou du système.
• Modification des données sensibles du système.
• Suppression des données sensibles du système.
• L’utilisateur peut se connecter à l’application en tant qu’autre utilisateur, même en tant qu’administrateur.
• L’utilisateur peut afficher des informations privées appartenant à d’autres utilisateurs, par exemple les détails des profils d’autres utilisateurs, les détails des transactions, etc.
• L’utilisateur peut modifier les informations de configuration de l’application et les données des autres utilisateurs.
• L’utilisateur peut modifier la structure de la base de données ; même supprimer des tables dans la base de données de l’application.
• L’utilisateur peut prendre le contrôle du serveur de base de données et y exécuter des commandes à volonté.

Les risques énumérés ci-dessus peuvent vraiment être considérés comme graves, car la restauration d’une base de données ou de ses données peut coûter cher. Cela peut coûter à votre entreprise une réputation et de l’argent pour restaurer les données et le système perdus. Par conséquent, il est fortement recommandé de protéger votre système contre ce type d’attaque et de considérer les tests de sécurité comme un bon investissement dans la réputation de votre produit et de votre entreprise.

En tant que testeur, je voudrais dire que tester contre d’éventuelles attaques est une bonne pratique même si les tests de sécurité n’étaient pas prévus. De cette façon, vous pouvez protéger et tester le produit contre les cas inattendus et les utilisateurs malveillants.

L’essence de cette attaque

Comme mentionné précédemment, l’essence de cette attaque est de pirater la base de données à des fins malveillantes.

Afin d’effectuer ce test de sécurité, vous devez d’abord trouver les parties vulnérables du système, puis envoyer du code SQL malveillant à la base de données. Si cette attaque est possible pour un système, alors le code SQL malveillant approprié sera envoyé et des actions nuisibles peuvent être effectuées dans la base de données.

Chaque champ d’un site Web est comme une porte d’accès à la base de données. Toutes les données ou entrées que nous saisissons habituellement dans n’importe quel champ du système ou du site Web vont à la requête de la base de données. Par conséquent, au lieu de données correctes, si nous tapons un code malveillant, il peut être exécuté dans la requête de base de données et entraîner des conséquences néfastes.

Pour effectuer cette attaque, nous devons modifier l’acte et le but d’une requête de base de données appropriée. L’une des méthodes possibles pour l’exécuter consiste à rendre la requête toujours vraie, puis à insérer votre code malveillant. La modification de la requête de base de données sur toujours vraie peut être effectuée avec un code simple comme ‘ ou 1=1;–.

Les testeurs doivent garder à l’esprit que tout en vérifiant si la modification de la requête en toujours vraie peut être effectuée ou non, différentes citations doivent être essayées – simples et doubles. Par conséquent, si nous avons essayé un code comme ‘ ou 1=1;–, nous devrions également essayer le code avec des guillemets doubles “ ou 1=1;–.

Par exemple , considérons que nous avons une requête, qui recherche le mot entré dans la table de la base de données :

select * from notes nt où nt.subject = ‘search_word’;

Par conséquent, au lieu du mot de recherche, si nous saisissons une requête d’injection SQL ‘ ou 1=1;–, la requête deviendra toujours vraie.

sélectionnez * à partir des notes nt où nt.subject = ‘ ‘ ou 1=1 ;–

Dans ce cas, le paramètre « sujet » est fermé par le guillemet et nous avons alors le code ou 1=1, ce qui rend une requête toujours vraie. Avec le signe « – » nous commentons le reste du code de la requête, qui ne sera pas exécuté. C’est l’un des moyens les plus populaires et les plus simples de commencer à contrôler la requête.

Quelques autres codes peuvent également être utilisés pour que la requête soit toujours vraie, comme :

• ‘ ou ‘abc’=’abc’;–
• ‘ ou ‘ ‘=’ ‘;–

La partie la plus importante ici est qu’après la virgule, nous pouvons entrer n’importe quel code malveillant que nous aimerions voir exécuter.

Par exemple , il peut s’agir de ‘ ou 1=1; déposer des notes de table ; –

Si cette injection est possible, alors tout autre code malveillant peut être écrit. Dans ce cas, cela ne dépendra que de la connaissance et de l’intention de l’utilisateur malveillant. Comment vérifier l’injection SQL ?

La vérification de cette vulnérabilité peut être effectuée très facilement. Parfois, il suffit de taper ‘ ou ” signer dans les champs testés. S’il renvoie un message inattendu ou extraordinaire, alors nous pouvons être sûrs que l’injection SQL est possible pour ce champ.

Par exemple , si vous obtenez un message d’erreur comme « Erreur de serveur interne » comme résultat de recherche, nous pouvons être sûrs que cette attaque est possible dans cette partie du système.

D’autres résultats, qui peuvent signaler une éventuelle attaque, incluent :

• Page vierge chargée.
• Pas de messages d’erreur ou de réussite – la fonctionnalité et la page ne réagissent pas à l’entrée.
• Message de réussite pour le code malveillant.

Voyons comment cela fonctionne dans la pratique.

Par exemple, testons si une fenêtre de connexion appropriée est vulnérable à l’injection SQL. À cette fin, dans le champ adresse e-mail ou mot de passe, il suffit de taper le signe comme indiqué ci-dessous.

Si une telle entrée renvoie un résultat comme le message d’erreur « Erreur de serveur interne » ou tout autre résultat inapproprié répertorié, nous pouvons presque être sûrs que cette attaque est possible pour ce champ.

Un très délicat code d’injection SQL peut également être essayé. Je voudrais mentionner que dans ma carrière, je n’ai rencontré aucun cas où il y avait un message “Erreur de serveur interne” à la suite du signe, mais parfois les champs ne réagissaient pas pour un code SQL plus compliqué.

Par conséquent, la vérification de l’injection SQL avec un guillemet simple ‘ est un moyen assez fiable de vérifier si cette attaque est possible ou non.

Si le guillemet simple ne renvoie aucun résultat inapproprié, nous pouvons essayer d’entrer des guillemets doubles et vérifier les résultats.

De plus, le code SQL pour changer la requête en toujours vrai peut être considéré comme un moyen de vérifier si cette attaque est possible ou non. Il ferme le paramètre et modifie la requête en « true ». Par conséquent, si elle n’est pas validée, une telle entrée peut également renvoyer tout résultat inattendu et informer celui-ci que cette attaque est possible dans ce cas.

La vérification d’éventuelles attaques SQL peut également être effectuée à partir du lien du site Web. Supposons que nous ayons un lien vers un site Web comme http://www.testing.com/books=1 . Dans ce cas, « books » est un paramètre et « 1 » est sa valeur. Si dans le lien fourni, nous écrivions ‘ signe au lieu de 1, alors nous vérifierions une éventuelle injection.

Par conséquent, le lien http://www.testing.com/books= sera comme un test si l’attaque SQL est possible pour le site http://www.testing.com ou non.

Dans ce cas, si le lien http://www.testing.com/books= renvoie un message d’erreur comme « Erreur de serveur interne » ou une page vierge ou tout autre message d’erreur inattendu, nous pouvons également être sûrs que l’injection SQL est possible pour ce site Web. Plus tard, nous pouvons essayer d’envoyer du code SQL plus compliqué via le lien du site Web.

Pour vérifier si cette attaque est possible via le lien du site Web ou non, un code comme ‘ ou 1=1;– peut également être envoyé.

En tant que testeur de logiciels expérimenté, je voudrais rappeler que non seulement le message d’erreur inattendu peut être considéré comme une vulnérabilité d’injection SQL. De nombreux testeurs ne recherchent d’éventuelles attaques qu’en fonction des messages d’erreur.

Cependant, il ne faut pas oublier qu’aucun message d’erreur de validation ou message de réussite de code malveillant ne peut également être un signe, que cette attaque est possible.

Test de sécurité des applications Web contre l’injection SQL

Tests de sécurité des applications Web expliqués avec des exemples simples :

Étant donné que les conséquences de l’autorisation de cette technique de vulnérabilité pourraient être graves, il s’ensuit que cette attaque doit être testée lors des tests de sécurité d’une application. Maintenant, avec un aperçu de cette technique, comprenons quelques exemples pratiques d’injection SQL.

Important : ce test d’injection SQL doit être testé uniquement dans l’environnement de test.

Si l’application dispose d’une page de connexion, il est possible que l’application utilise du SQL dynamique tel que l’instruction ci-dessous. Cette instruction doit renvoyer au moins une ligne avec les détails de l’utilisateur de la table Users comme jeu de résultats lorsqu’il existe une ligne avec le nom d’utilisateur et le mot de passe entrés dans l’instruction SQL.

SELECT * FROM Users WHERE User_Name = '" & strUserName & "' AND Password = '" & strPassword & "';" 

Si le testeur écrivait John comme strUserName (dans la zone de texte pour le nom d’utilisateur) et Smith comme strPassword (dans la zone de texte pour le mot de passe), l’instruction SQL ci-dessus deviendrait :

SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;

Si le testeur écrivait John’– comme strUserName et pas strPassword, l’instruction SQL deviendrait :

SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;

Notez que la partie de l’instruction SQL après John est transformée en commentaire. S’il y avait un utilisateur avec le nom d’utilisateur de John dans la table Users, l’application pourrait permettre au testeur de se connecter en tant qu’utilisateur John. Le testeur pouvait maintenant voir les informations privées de l’utilisateur John.

Que faire si le testeur ne connaît pas le nom d’un utilisateur existant de l’application ? Dans un tel cas, le testeur peut essayer des noms d’utilisateur courants tels que admin, administrator et sysadmin. Si aucun de ces utilisateurs n’existe dans la base de données, le testeur peut saisir John’ ou ‘x’=’x comme strUserName et Smith’ ou ‘x’=’x comme strPassword. Cela ferait en sorte que l’instruction SQL deviendrait comme celle ci-dessous.

SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;

Étant donné que la condition ‘x’=’x’ est toujours vraie, le jeu de résultats consisterait en toutes les lignes de la table Users. L’application pourrait permettre au testeur de se connecter en tant que premier utilisateur dans la table Utilisateurs.

mportant : le testeur doit demander à l’administrateur de la base de données ou au développeur de copier la table en question avant de tenter les attaques suivantes.

Si le testeur entrerait dans John’; DROP table users_details;’—comme strUserName et n’importe quoi comme strPassword, l’instruction SQL deviendrait comme celle ci-dessous.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';

Cette instruction peut entraîner la suppression définitive de la table « users_details » de la base de données.

Bien que les exemples ci-dessus traitent de l’utilisation de la technique d’injection SQL uniquement sur la page de connexion, le testeur doit tester cette technique sur toutes les pages de l’application qui acceptent les entrées utilisateur au format texte, par exemple les pages de recherche, les pages de commentaires, etc.

L’injection SQL peut être possible dans les applications qui utilisent SSL. Même un pare-feu peut ne pas être en mesure de protéger l’application contre cette technique.

J’ai essayé d’expliquer cette technique d’attaque sous une forme simple. Je voudrais réitérer que cette attaque doit être testée uniquement dans un environnement de test et non dans l’environnement de développement, l’environnement de production ou tout autre environnement.

Au lieu de tester manuellement si l’application est vulnérable aux attaques SQL ou non, on pourrait utiliser un Web Vulnerability Scanner qui vérifie cette vulnérabilité.

Lecture connexe : Tests de sécurité de l’application Web . Vérifiez ceci pour plus de détails sur les différentes vulnérabilités Web.

Parties vulnérables de cette attaque

Avant de commencer le processus de test, tout testeur sincère devrait plus ou moins savoir quelles parties seraient les plus vulnérables à cette éventuelle attaque.

C’est aussi une bonne pratique de planifier quel domaine du système doit être testé exactement et dans quel ordre. Au cours de ma carrière de testeur, j’ai appris que ce n’est pas une bonne idée de tester les champs contre les attaques SQL au hasard, car certains champs peuvent être manqués.

Comme cette attaque est effectuée dans la base de données, toutes les parties du système de saisie de données, les champs de saisie et les liens de sites Web sont vulnérables.

Les parties vulnérables comprennent :

• Champs de connexion
• Champs de recherche
• Comment fields
• Tout autre champ de saisie et d’enregistrement de données
• Liens du site

Il est important de noter que lors des tests contre cette attaque, il ne suffit pas de vérifier un ou quelques champs. Il est assez courant qu’un champ soit protégé contre l’injection SQL, mais pas un autre. Il est donc important de ne pas oublier de tester tous les champs du site.

Automatisation des tests d’injection SQL

Comme certains systèmes ou sites Web testés peuvent être assez compliqués et contenir des données sensibles, les tests manuels peuvent être très difficiles et cela prend également beaucoup de temps. Par conséquent, tester contre cette attaque avec des outils spéciaux peut parfois être très utile.

L’un de ces outils d’injection SQL est l’ interface utilisateur SOAP . Si nous avons des tests de régression automatisés au niveau de l’API, nous pouvons également basculer la vérification contre cette attaque à l’aide de cet outil. Dans l’outil d’interface utilisateur SOAP, il existe déjà des modèles de code préparés pour lutter contre cette attaque. Ces modèles peuvent également être complétés par votre propre code écrit.

C’est un outil assez fiable.

Cependant, un test devrait déjà être automatisé au niveau de l’API, ce qui n’est pas si simple. Une autre façon possible de tester automatiquement est d’utiliser divers plugins de navigateur.

Il convient de mentionner que même si les outils automatisés vous font gagner du temps, ils ne sont pas toujours considérés comme très fiables. Si nous testons un système bancaire ou tout autre site Web contenant des données très sensibles, il est fortement recommandé de le tester manuellement. Où vous pouvez voir les résultats exacts et les analyser. De plus, dans ce cas, nous pouvons être sûrs que rien n’a été ignoré.

Comparaison avec d’autres attaques

L’injection SQL peut être considérée comme l’une des attaques les plus graves, car elle influence la base de données et peut endommager gravement vos données et l’ensemble du système.

Bien sûr, cela peut avoir des conséquences plus graves qu’une injection Javascript ou une injection HTML, car les deux sont effectuées côté client. A titre de comparaison, avec cette attaque, vous pouvez avoir accès à toute la base de données.

Il convient de mentionner que pour tester contre cette attaque, vous devez avoir une assez bonne connaissance du langage de programmation SQL et, en général, vous devez savoir comment fonctionnent les requêtes des bases de données. De plus, lors de l’exécution de cette attaque par injection, vous devez être plus prudent et attentif, car toute inexactitude peut être laissée en tant que vulnérabilités SQL.

Conclusion

J’espère que vous auriez une idée claire de ce qu’est une injection SQL et de la façon dont nous devrions empêcher ces attaques.

Cependant, il est fortement recommandé de tester contre ce type d’attaque chaque fois qu’un système ou un site Web avec une base de données est testé. Toute vulnérabilité de base de données ou de système laissée en place peut coûter la réputation d’une entreprise et beaucoup de ressources pour restaurer l’ensemble du système.

Comme les tests contre cette injection aident à trouver les les plus vulnérabilités de sécurité importantes , il est également recommandé d’investir dans vos connaissances et vos outils de test.

Si des tests de sécurité sont planifiés, les tests par rapport à l’injection SQL doivent être planifiés comme l’une des premières parties de test.

Avez-vous rencontré une injection SQL typique ? N’hésitez pas à partager vos expériences dans la section commentaires ci-dessous.

Votez : (10 votes, average: 3,90 out of 5)

Loading...