Article
Injection SQL
Quel est le principe d’une injection SQL?
La famille des injections SQL (Structured Query Language) regroupe un grand nombre de vulnérabilités qui ont en commun l’interaction avec une base de données SQL.
C’est quoi une attaque par injection sql?
Cette faille est apparue pour la première fois en 1998, notamment dans un article du Phrack Magazine (SQL injection – Wikipedia)
Dans les Top 10 de l’OWASP (2007, 2010, 2013, 2017), l’injection SQL a été positionnée en première position, avec les autres injections (OWASP Top Ten Web Application Security Risks | OWASP)
L’injection SQL s’attaque aux bases de données, ce qui en fait donc une vulnérabilité touchant le côté serveur des applications web. Les failles SQL sont présentes lorsque le serveur utilise les entrées utilisateurs sans les filtrer pour lancer une ou plusieurs requêtes SQL.
Découvrez aussi notre article « Comment se protéger contre le TOP 10 de l’OWASP? »
Quels sont les différents types d’injections SQL ?
Différentes méthodes d’exploitation des failles SQL existent et s’adaptent selon ce que le serveur permet. Parmi les plus connues :
Faille SQL « classique » (avec ‘OR 1=1 –) :
C’est la faille SQL par excellence, notamment présente sur les formulaires d’authentification, elle permet de se connecter à n’importe quel compte utilisateurs.
Faille SQL « Union-based » :
En langage SQL, l’opérateur UNION permet de fusionner le résultat de 2 requêtes, cela permet d’ajouter les données souhaitées aux données présentes dans la première requête SQL.
Faille SQL « Blind » :
Présente lorsque les données récupérées ne sont pas affichées à l’écran, l’attaquant utilisera une condition lui permettant de mettre en pause et se basera sur le temps de réponse du système pour savoir si son injection est réussie, cette technique est notamment utilisée pour « brute forcer » les données que l’on souhaite récupérer.
De nombreuses autres méthodes d’injections SQL, de la vulnérabilité « Error Based » permettant d’afficher des valeurs dans un message d’erreur à la « Stacked Query » qui donne la possibilité d’effectuer n’importe quelles requêtes. Il est à noter que les bases de données NoSQL possèdent aussi leurs vulnérabilités.
Conséquences d’une attaque par injections SQL
Les injections SQL engendrent trois gros problèmes :
- 1. La récupération des données : probablement le problème le plus connu lié aux injections SQL, avec la possibilité d’ajouter des requêtes personnalisées, un attaquant peut récupérer n’importe quelles données présentes dans une base SQL.
- 2. Le vol de compte : lorsqu’une injection SQL est possible sur un formulaire de connexion, il est très facile pour un attaquant de s’authentifier avec un compte ne lui appartenant pas.
- 3. Corruption des données : cas le plus dangereux, exploité avec les Stacked Querry.
Il est très courant que des bases de données fuitent avec les informations personnelles des utilisateurs (nom, mail, adresse).
Cela implique qu’il faut porter une grande attention aux données sensibles qui pourraient être stockées en ligne.
Outre l’usurpation d’identité ou le vol de données, c’est le bon fonctionnement d’une application web qui peut être mis en cause si un compte administrateur est récupéré.
Un attaquant qui a la possibilité d’effectuer n’importe quelles requêtes sur une base de données SQL peut très facilement modifier ou supprimer des données.
En plus de la corruption qui peut être problématique pour des informations importantes, cela peut mener aux mêmes problèmes que ceux cités plus haut : Un pirate pouvant modifier un mot de passe est un attaquant qui connaît le mot de passe.
La plupart des sites web stockent leurs contenus dans une base de données, si un hacker y a accès, il peut alors pratiquer le « defacing » ou publier des fakes news.
Comment faire une injection SQL ?
Utilisation normale d’une barre de recherche (PHP & MYSQL)
Prenons l’exemple d’un site de vente d’outil en ligne. Sur l’une des pages de l’application web se trouve une barre de recherche permettant de trouver un article avec son nom et son prix.
Loris, l’attaquant va d’abord effectuer une recherche simple pour voir les différents modèles de tondeuse.
Lorsqu’il cliquera sur le bouton le serveur va récupérer son entrée et l’insérer dans une requête SQL.
Le serveur enverra alors cette commande SQL à la base de données qui l’exécutera en tant que code.
Cette dernière ira alors chercher dans la table « articles » tout le nom et le prix des éléments contenant « tondeuse » dans leur nom et avec un stock supérieur à zéro.
Le serveur récupérera ces informations et pourra ensuite les afficher sur l’écran de Loris.
Test d’une injection SQL
Loris voit que sa recherche a été ajoutée à l’url sous la forme « ?name=tondeuse »
Il décide alors de tester si ce paramètre permet de rentrer du code SQL
Il rajoute un « ‘ » qui permet d’ouvrir et de ferme une chaîne de caractères en SQL
La base de données recevra alors la commande SQL suivante :
Cette requête n’est pas valide, le deuxième « % » se retrouvant hors string est considéré comme un caractère interdit
Une erreur est alors renvoyée : « MySQL error : Invalid Syntax »
Loris sait maintenant qu’une base de données MySQL est utilisée.
Afin d’éviter cette erreur Loris rajoute un commentaire MySQL à sa requête, cela va lui permettre d’enlever le reste de la commande grâce à la syntaxe « ‘– »
Cette fois la base de données accepte la requête et va renvoyer tous les articles, le pourcentage faisant office de wildcard, notamment ceux n’étant plus en stock, la condition étant supprimée
Loris n’a plus qu’à ajouter ses propres requêtes pour exploiter la vulnérabilité.
Exemple d’Injection SQL
Maintenant que Loris possède une requête valide, l’attaque par injection SQL va pouvoir commencer
Son objectif va être de récupérer les mots de passe des utilisateurs stockés dans la base de données
Il lui faut tout d’abord invalider la requête actuelle pour ne pas récupérer les informations sur les articles, pour cela, un simple « AND 1=2 — » va suffire.
La requête va donc chercher à récupérer les articles si la condition 1=2 est validé, par conséquent, il n’y aura plus aucun résultat.
Loris va ensuite utiliser l’opérateur UNION qui permet de fusionner des requêtes et ajouter un SELECT lui permettant de récupérer le nom des différentes tables.
Avec quelques autres requêtes SQL sur différentes tables, Loris va découvrir que Paul est l’administrateur du site, il va donc récupérer son mot de passe.
Le mot de passe est donc cb28e00ef51374b841fb5c189b2b91c9.
Evidemment les mots de passe ne sont jamais stocké en clair et ce format semble être celui d’un hash MD5
Le MD5 est un algorithme utilisé pour encrypter un texte, on ne peut pas l’inverser mais, des sites (https://md5decrypt.net/ par exemple) stockent beaucoup de correspondance texte – hash MD5.
Loris est chanceux et retrouve le mot de passe associé au hash : password123456
Loris n’a plus qu’à s’authentifier avec la paire Paul / password123456 pour avoir accès à un compte administrateur.
Dans notre exemple, l’attaque par injection SQL a été effectuée manuellement.
Cependant, il existe aujourd’hui des outils tels que SQLMap qui permettent de faciliter la détection de ces attaques avec des scripts pré faits.
OWASP recommendation
L’Open Web Application Security Project (OWASP) fournit un guide pour se éviter les SQL injections, nous allons résumer ici les différentes options qui s’offrent à un développeur.
Les requêtes préparées qui consistent à écrire des requêtes SQL et y ajouter les paramètres plus tard. Cette méthode permet d’insérer des paramètres en évitant l’injection de caractères d’échappement.
Utiliser une « whitelist » (une liste de valeurs autorisée) permet de restreindre le champ d’action de l’utilisateur et de n’accepter que des valeurs paramétrées en amont
Echapper les entrées utilisateurs restent une manière efficace d’éviter tout caractère d’échappement
Comment trouver une faille SQL ? Quel est le meilleur moyen de se prémunir des injections SQL ?
UBIKA Cloud protector vs injections SQL
Pour éviter les différents types d’injections SQL, UBIKA Cloud Protector fournit plusieurs outils :
Le « Blacklisting» utilisé sur tous les niveaux de protection : si UBIKA Cloud Protector détecte un pattern habituellement utilisé pour exploiter une faille SQL, la requête sera immédiatement bloquée et redirigée.
« Scoring List» active sur les niveaux Advanced et High de protection : UBIKA Cloud Protector va analyser la requête et incrémenter un score au fur et à mesure des patterns malicieux rencontrés. A la fin de l’analyse, si le score est supérieur à la limite autorisée la requête est bloquée et redirigée. Cette méthode à l’avantage d’être beaucoup plus fine et d’éviter les faux positifs.
