Menu

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

  • Principal
  • Test Web
  • Tutoriel de test d'injection SQL (exemple et prévention des attaques par injection SQL)

sql injection testing tutorial example

Essayez Notre Instrument Pour Éliminer Les Problèmes

ajouter à un tableau en java

Exemples d'injection SQL et moyens de prévenir 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 le plus protégé possible.

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

Exemple de connexion d

L'injection SQL est considérée comme l'une des attaques les plus courantes car elle peut avoir des conséquences graves et nuisibles sur votre système et vos données sensibles.

Ce que vous apprendrez:

Qu'est-ce que l'injection SQL?

Certaines des entrées utilisateur peuvent être utilisées dans le cadrage Instructions SQL qui sont ensuite exécutés par l'application sur la base de données. Il est possible pour une application de NE PAS gérer correctement les entrées fournies par l'utilisateur.

Si c'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 entre les données de connexion, dans le champ de recherche, l'utilisateur entre un texte de recherche, dans le formulaire de sauvegarde des données, l'utilisateur entre les données à sauvegarder. 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 des dommages sérieux 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.

Il s'agit de 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 en cours de test peut avoir une interface utilisateur qui accepte les entrées de l'utilisateur qui est utilisée pour effectuer les tâches suivantes:

#1) Afficher les données stockées pertinentes à l'utilisateur, par ex. 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 les données pertinentes à l'utilisateur

#deux) Enregistrez les données saisies par l'utilisateur dans la base de données, par ex. une fois que l'utilisateur remplit un formulaire et le soumet, 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

Risques d'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.

Étant donné que les données sensibles sont stockées dans la base de données, la sécurité du système comporte davantage de risques. Si les données d'un site Web ou d'un blog personnel étaient volés, il n'y aurait pas beaucoup de dommages par rapport aux données qui seraient volées au système bancaire.

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

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 ex. détails des profils des autres utilisateurs, 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. La restauration des données et du système perdus peut coûter une réputation et de l'argent à votre entreprise. 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 faire remarquer que les tests contre d'éventuelles attaques sont une bonne pratique même si Test de sécurité n'était pas prévu. 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.

Pour effectuer ce test de sécurité, vous devez d'abord rechercher 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, un 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 généralement 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 saisissons 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.

Outil recommandé

# 1) Kiuwan

bannière kiuwan

Trouvez et corrigez facilement les vulnérabilités telles que l'injection SQL dans votre code à chaque étape du SDLC. Kiuwan est conforme aux normes de sécurité les plus strictes, notamment OWASP, CWE, SANS 25, HIPPA, etc.

Intégrez Kiuwan dans votre IDE pour un retour instantané pendant le développement. Kiuwan prend en charge tous les principaux langages de programmation et s'intègre aux principaux outils DevOps.

=> Scannez votre code gratuitement

Pour effectuer cette attaque, nous devons changer 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 est de rendre la requête toujours vraie et ensuite d'insérer votre code malveillant. La modification de la requête de la base de données sur toujours vrai peut être effectuée avec un code simple comme ‘ou 1 = 1; -.

Essence de l

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

Essentiel de l

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

sélectionnez * parmi les notes nt où nt.subject = ‘search_word’;

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

sélectionnez * dans les notes nt où nt.subject = ‘’ ou 1 = 1; -

Dans ce cas, le paramètre «sujet» est fermé par le guillemet et alors nous avons le code ou 1 = 1, ce qui rend une requête toujours vraie. Avec le signe «-», nous commentons le reste du code de 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.

Peu d'autres codes peuvent également être utilisés pour rendre la requête toujours vraie, comme:

  • «Ou« abc »=« abc »; -
  • «Ou« »=« »; -

La partie la plus importante ici est qu'après le signe virgule, nous pouvons entrer n'importe quel code malveillant, que nous aimerions être exécuté.

Par exemple, il peut être «ou 1 = 1; déposer des notes de table; -

Supprimer les notes de table

Si cette injection est possible, tout autre code malveillant peut être écrit. Dans ce cas, cela ne dépendra que des connaissances 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, 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 interne du serveur' comme résultat de la recherche, nous pouvons être sûrs que cette attaque est possible dans cette partie du système.

D'autres résultats, qui peuvent notifier une attaque possible, comprennent:

  • Page vierge chargée.
  • Aucun message d'erreur ou de réussite - la fonctionnalité et la page ne réagissent pas à l'entrée.
  • Message de réussite pour un code malveillant.

Voyons comment cela fonctionne dans la pratique.

Par exemple, Testons si une fenêtre de connexion appropriée est vulnérable pour l'injection SQL. À cette fin, dans le champ de l'adresse e-mail ou du mot de passe, nous tapons simplement le signe comme indiqué ci-dessous.

Adresse e-mail

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

Erreur Interne du Serveur

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 interne du serveur» à 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 de saisir des guillemets doubles et vérifier les résultats.

Simple citation

De plus, le code SQL permettant de 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 remplace la requête par «vrai». Par conséquent, si elle n'est pas validée, une telle entrée peut également retourner tout résultat inattendu et informer le même, que cette attaque est possible dans ce cas.

Essentiel de l

La recherche 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, «livres» est un paramètre et «1» est sa valeur. Si dans le lien fourni, nous écrivions «signe au lieu de 1, nous vérifierions une éventuelle injection.

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

Lien de test

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

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

Liens de test

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 vérifient les attaques possibles uniquement en fonction des messages d'erreur.

Cependant, il ne faut pas oublier qu'aucun message d'erreur de validation ou de succès pour un code malveillant ne peut également être un signe que cette attaque est possible.

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

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

Étant donné que les conséquences de l'autorisation de cette technique de vulnérabilité peuvent ê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, laissez-nous comprendre 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 seule ligne avec les détails de l'utilisateur de la table Users en tant que jeu de résultats lorsqu'il existe une ligne avec le nom d'utilisateur et le mot de passe saisis dans l'instruction SQL.

SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & '’; '

Si le testeur saisissait John comme strUserName (dans la zone de texte pour username) et Smith comme strPassword (dans la zone de texte pour mot de passe), l'instruction SQL ci-dessus deviendrait:

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

Si le testeur saisissait 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 afficher 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'utilisateurs 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 devienne 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 comprend toutes les lignes de la table Users. L'application peut permettre au testeur de se connecter en tant que premier utilisateur dans le tableau Utilisateurs.

Important: 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 saisissait John »; DROP table users_details; »- en tant que strUserName et quoi que ce soit en tant que 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 pourrait entraîner la suppression définitive de la table «user_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 de l'utilisateur au format textuel, par exemple. pages de recherche, 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 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.

comment utiliser un fichier torrent après le téléchargement

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

Lecture connexe: Test 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, chaque testeur sincère devrait savoir plus ou moins quelles parties seraient les plus vulnérables à une éventuelle attaque.

Il est également recommandé de planifier exactement quel domaine du système doit être testé et dans quel ordre. Dans ma carrière de testeur, j'ai appris que ce n'est pas une bonne idée de tester des champs contre des attaques SQL de manière aléatoire 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
  • Champs de commentaire
  • Tout autre champ de saisie et d'enregistrement de données
  • Liens du site Web

Il est important de noter que lors du test contre cette attaque, il ne suffit pas de vérifier seulement 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 prendre également beaucoup de temps. Par conséquent, des tests contre cette attaque avec des outils spéciaux peuvent parfois être très utiles.

Un de ces outils d'injection SQL est 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 SOAP UI, il existe déjà des modèles de code préparés pour vérifier 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 consiste à utiliser divers plugins de navigateur.

Il faut 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 site Web avec 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 sérieusement 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 à l'ensemble de 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 de bases de données. De plus, lors de cette attaque par injection, vous devez être plus prudent et plus 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 comment éviter ces attaques.

Cependant, il est fortement recommandé de tester 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 peut coûter à la réputation d'une entreprise et beaucoup de ressources pour restaurer l'ensemble du système.

Comme le test contre cette injection aide à trouver le 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 prévus, 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.

lecture recommandée

^