Qu'est-ce que l'Injection SQL ?

SQLi est une sorte d'attaque dans une application Web où l'attaquant peut exécuter des requêtes malveillantes dans la base de données d'un site Web. SQL est une technique d'injection de code utilisée pour exécuter des instructions SQL malveillantes.

Par exemple, si vous souhaitez vous connecter au site Web et que vous avez oublié le nom d'utilisateur et le mot de passe, en utilisant l'injection SQLi, nous pouvons nous connecter ou accéder à la page Web sans connaître le mot de passe.

Comment fonctionne l'injection SQL ?

L'injection SQL contient l'insertion ou l'injection de la requête SQL via les données d'entrée du client dans l'application. Ceux-ci sont injectés dans le plan de données qui affectent les commandes SQL prédéfinies.

Les attaques par injection SQL ciblent les vulnérabilités dans les instructions SQL dynamiques. Considérez une instruction SQL dynamique comme une fonction mathématique multivariée dont les paramètres sont fixes tandis que le résultat est déterminé par les valeurs placées dans les variables indépendantes.

De même, une instruction SQL dynamique consiste également en un ensemble prédéfini de paramètres (tel qu'un formulaire Web) et l'instruction complète n'est générée que lorsque l'utilisateur fournit une entrée.

Consultez l'exemple suivant d'instruction SQL d'un formulaire de connexion :

SELECT * FROM users WHERE username = '$username' AND password = bcrypt ('$password')

Si une vulnérabilité existe dans une instruction SQL dynamique, un attaquant pourrait saisir un script complexe dans un formulaire pour corrompre les paramètres existants et modifier la signification de l'intégralité de l'instruction.

Types d'injection SQL :

SQLi intrabande : l'injection SQL intrabande est un type d'injection SQL dans lequel l'attaquant reçoit le résultat sous forme de réponse directe via le même canal de communication. Par exemple, si un attaquant lance manuellement une attaque via son navigateur Web, les résultats de l'attaque seront affichés dans le même navigateur Web. L'injection SQL intrabande est également connue sous le nom d'injection SQL traditionnelle.

Injection SQL basée sur les erreurs - Ici, l'attaquant effectue certaines actions qui provoquent la génération d'un message d'erreur par la base de données. Vous pouvez utiliser le message d'erreur pour déterminer quelle base de données est utilisée, quelle version de serveur le gestionnaire utilise, etc.

Injection SQL basée sur l'union — Une instruction générée par la base de données pour obtenir une réponse HTTP unique. Vous pouvez construire la requête dans l'URL ou combiner plusieurs déclarations dans le champ de saisie pour essayer de générer la réponse

Blind SQLi : L'injection SQL aveugle est un type d'injection SQL dans lequel l'attaquant n'obtient pas de réponse explicite de la base de données attaquée, mais observe à la place le comportement du serveur de base de données et de l'application pour reconstruire la structure de la base de données de manière incrémentielle. L'injection SQL aveugle est également connue sous le nom d'injection SQL inférentielle.

Boolean Based - Ici, l'attaquant envoie une requête SQL à la base de données et demande à l'application de renvoyer des résultats différents selon que la requête renvoie True ou False.

Basé sur le temps - Dans cette attaque, un attaquant soumet une requête SQL à une base de données et fait attendre la base de données pendant un certain temps avant de partager les résultats. Le temps de réponse aide un attaquant à déterminer si une requête est vraie ou fausse.

SQLi hors bande : l'injection SQL hors bande (OOB SQLi) est un type d'injection SQL dans lequel l'attaquant ne reçoit pas de réponse de l'application attaquée sur le même canal de communication, mais peut être amené à envoyer données à un terminal distant contrôlé par l'attaquant. L'injection SQL hors bande n'est possible que si le serveur que vous utilisez dispose de commandes qui déclenchent des requêtes DNS ou HTTP. Cependant, cela s'applique à tous les serveurs SQL populaires.

Exemple sur SQLi

Le premier exemple est très simple. Il montre comment un attaquant peut utiliser une vulnérabilité d'injection SQL pour contourner la sécurité des applications et s'authentifier en tant qu'administrateur.

Le script suivant est un pseudocode exécuté sur un serveur Web. C'est un exemple simple d'authentification avec un nom d'utilisateur et un mot de passe. L'exemple de base de données a une table nommée usersavec les colonnes suivantes : usernameet password.

# Define POST variables
uname = request.POST['username']
passwd = request.POST['password']
# SQL query vulnerable to SQLi
sql = “SELECT id FROM users WHERE username=’” + uname + “’ AND password=’” + passwd + “’”
# Execute the SQL statement
database.execute(sql)

password' OR 1=1

SELECT id FROM users WHERE username='username' AND password='password' OR 1=1'

-- MySQL, MSSQL, Oracle, PostgreSQL, SQLite
' OR '1'='1' --
' OR '1'='1' /*
-- MySQL
' OR '1'='1' #
-- Access (using null characters)
' OR '1'='1' %00
' OR '1'='1' %16

Les organisations peuvent appliquer les stratégies suivantes pour se protéger contre les attaques par injection SQL.

1. Ne faites jamais confiance à l'entrée de l'utilisateur. Ils doivent toujours être nettoyés avant de les utiliser dans des instructions SQL dynamiques.
   Procédures stockées — Vous permet d'encapsuler des instructions SQL et de traiter toutes les entrées comme des paramètres.
2. Instructions préparées — Instructions préparées qui fonctionnent en construisant d'abord une instruction SQL, puis en traitant les données utilisateur soumises en tant que paramètres. Cela n'affecte pas la syntaxe des instructions SQL.
   Expressions régulières — peuvent être utilisées pour détecter un code potentiellement malveillant et le supprimer avant l'exécution d'une instruction SQL.
3. Autorisations utilisateur de connexion à la base de données — Le compte utilisé pour se connecter à la base de données ne doit recevoir que les autorisations nécessaires. Cela permet de réduire les performances des instructions SQL sur le serveur.
4. Messages d'erreur — Ceux-ci ne révèlent pas d'informations sensibles ni l'emplacement exact de l'erreur. "Désolé, une erreur technique s'est produite. J'ai contacté l'équipe technique. Réessayez plus tard » au lieu d'afficher l'instruction SQL à l'origine de l'erreur.

C'est exactement ce que fait un pare-feu d'application Web (WAF). Analysez toutes les entrées utilisateur dans votre application Web pour rechercher des correspondances avec du code suspect.

Nous espérons que vous avez compris la comparaison et compris les concepts.

Laissez un commentaire et partagez vos pensées !!

Auteurs:

Akash Shekhavat, Madhuri Shelke, Chetan Shinde, Swarali Sole

Références:

https://learn.microsoft.com/en-us/sql/relational-databases/security/sql-injection?view=sql-server-ver16

https://systemweakness.com/sql-injection-attacks-53e942aae1f8

https://qawerk.com/blog/what-is-sql-injection/

https://brightsec.com/blog/sql-injection-attack/