Le test d’intrusion, ou pentest, permet de rechercher et d’identifier les failles de sécurité informatique d’un système ou d’une application. L’une des failles couramment utilisée lors d’une attaque informatique est l’injection SQL. Elle peut permettre au hacker d’obtenir des informations sur la base de données elle-même ou pire, des données qu’elle contient. Il est donc particulièrement important de protéger son site web ou son application contre ce type d’attaque et de bien la prendre en compte dans votre politique de cybersécurité.
Découvrez les différents types de test d’intrusion web.
Qu’est-ce qu’une Injection SQL ?
Le SQL (Structured Query Langage, ou langage de requête structurée) est le langage le plus communément utilisé pour interroger une base de données. Il permet d’écrire des requêtes permettant de créer, lire, ajouter ou supprimer des données dans une base.
Si votre site n’est pas correctement protégé contre ce type d’attaque, un hacker peut être en mesure d’exécuter des requêtes SQL sur votre base de données (l’injection SQL). Il peut ainsi interroger la base de données, en extraire son contenu, et donc potentiellement des informations confidentielles. Plusieurs entreprises ces dernières années, parfois importantes, ont été victimes d’une attaque par injection SQL. Des millions d’informations confidentielles concernant leurs utilisateurs ont ainsi pu être récupérées et éventuellement utilisées.
Le problème prend encore une autre dimension si au lieu de se « contenter » de voler les données (confidentialité des données), le hacker les supprime (disponibilité des données) ou les modifie (intégrité des données). Les données étant au cœur de l’entreprise, si elles sont détruites ou compromises, c’est une perte potentiellement irremplaçable.
Comment fonctionne une attaque par injection SQL ?
Les injections SQL sont majoritairement utilisées à partir de formulaires mis à disposition sur un site ou une application web. Généralement, des informations sont saisies dans le formulaire puis envoyées au serveur. Elles sont alors prises en charge par les programmes constituant le site et elles sont généralement utilisées pour réaliser des opérations sur une base de données.
L’exemple le plus courant est le formulaire de connexion. L’utilisateur saisit un nom ou une adresse email et un mot de passe. Les informations sont envoyées au serveur, qui lance une interrogation sur la base de données pour savoir si cet utilisateur est connu et si le mot de passe saisi est correct. Suivant la réponse de la base de données, interrogée via une requête SQL, l’utilisateur sera finalement connecté ou non.
Normalement, sur un site sécurisé, les informations vont être vérifiées lors de leur saisie (on vérifie que le format du champ est respecté, type, longueur, caractères autorisés…) puis lors de leur récupération sur le serveur, avant d’être utilisées pour interroger la base de données. Si le contrôle des données du formulaire n’est pas fait correctement, alors rien n’empêche un hacker de saisir directement des instructions SQL dans le champ. Sans filtrage efficace, la requête SQL envoyée par le hacker via le formulaire peut alors être exécutée à la place de la requête prévue. Il peut donc potentiellement extraire n’importe quelle information stockée dans la base données. Il pourrait également s’enregistrer comme utilisateur et s’octroyer des droits lui permettant par exemple de gérer l’application.
Des variantes courantes
Il existe plusieurs variantes d’injections SQL ayant chacune un objectif particulier.
L’injection SQL en aveugle
Une application bien configurée n’affichera à l’utilisateur que des erreurs génériques, ne donnant par exemple aucune indication sur le type de base de données ou sa version. En envoyant des requêtes SQL en aveugle (c’est-à-dire sans connaître la structure de la base), le hacker va recevoir des réponses qu’il pourra analyser. C’est un moyen, long et complexe, d’obtenir des informations sur le modèle et la version du serveur de base de données, et sur les schémas utilisés.
L’injection SQL par l’erreur
L’objectif est de soumettre au système des requêtes SQL erronées et d’analyser les messages d’erreur obtenus afin d’obtenir des informations sur le modèle de base de données utilisé.
L’injection SQL par union
L’opérateur « union » en SQL permet de combiner les résultats de plusieurs requêtes SQL « select » (permettant de lire les données) en un seul. Cela permet éventuellement d’extraire d’importantes quantités de données en une seule fois.
L’injection SQL par empilement
Version la plus dangereuse des attaques par injection SQL, l’attaque par empilement a pour objectif d’exécuter plusieurs requêtes à la suite, en remplaçant la requête d’origine par la sienne.
Comment protéger son site ou son application ?
Environ 80% des sites web dans le monde sont construits à partir du langage PHP et beaucoup utilisent la base de données MySQL. Il existe naturellement des parades permettant de se protéger des attaques par injection SQL.
Filtrer les informations saisies par l’utilisateur
Le principe premier est « ne jamais faire confiance aux informations provenant de l’utilisateur ». Outre le fait de vérifier que les informations transmises sont bien celles que l’on attend (une chaîne de caractères, une adresse email, un nombre…), il faut également « échapper » les données provenant de l’utilisateur avant de les utiliser dans une requête SQL. Des fonctions natives du langage (telles que mysqli_real_escape_string() et htmlspecialchars() pour rester en PHP) permettent d’empêcher notamment qu’une chaîne de caractères puissent être interprétée comme une requête SQL et de convertir les caractères spéciaux.
Utiliser des requêtes préparées
L’utilisation de requêtes préparées permet de ne pas exécuter directement le code SQL. La requête est préalablement « préparée », c’est-à-dire qu’elle est convertie en modèle de requête. Ce n’est qu’au moment de son exécution que les différents paramètres sont intégrés après avoir été préalablement filtrés. Ainsi, aucun code SQL malveillant ne peut être exécuté.
Mettre en place un contrôle strict à la base de données
Si votre application ou votre site web se connectent à la base de données avec un utilisateur ayant des droits réduits (il ne peut que lire les données, et seulement provenant des tables dont l’application a besoin par exemple), la portée d’une injection SQL sera déjà considérablement réduite. Il est également possible de bloquer automatiquement certains mots-clés SQL directement au niveau du serveur web.
Vous pourriez également être intéressé par les articles suivants :
![Pentest Web Vulnérabilité CRSF](https://gplexpert.com/wp-content/uploads/2021/08/Pentest-Site-Web-Vulnerabilite-CRSF-300x169.jpg)
Pentest Web – Faille CSRF
Les attaques Web cherchant à utiliser une faille CSRF sont plutôt courantes, bien qu’elles puissent assez facilement être contrées. L’existence d’une vulnérabilité de type CSRF
Pentest Web – Faille XSS
La faille XSS (pour « Cross Site Scripting ») est sans aucun doute le problème le plus répandu en cybersécurité. Une offensive par une attaque