Accueil / Protection des données / Que sont les attaques par injection SQL ? Apprenez à protéger et à identifier une attaque
Les injections SQL font partie des types de cyberattaques les plus courants et les plus élémentaires. Malheureusement, une injection SQL est également l’une des menaces les plus dévastatrices auxquelles une application peut être confrontée. Ces attaques entraînent régulièrement des pertes de données et sont particulièrement dangereuses pour les infrastructures avec des bases de données partagées.
Cet article explique comment empêcher les injections SQL . Lisez la suite pour savoir ce que sont les injections SQL, comment ces attaques fonctionnent et quelles mesures les entreprises prennent pour protéger leurs bases de données contre les injections malveillantes.
Qu’est-ce Qu’une Attaque Par Injection SQL ?
L’injection SQL (SQLi) est une cyberattaque dans laquelle un pirate exécute des instructions SQL malveillantes via l’application pour manipuler la base de données. Ces attaques peuvent affecter n’importe quel site Web ou application Web qui s’appuie sur une base de données SQL (MySQL, Oracle, Sybase, Microsoft SQL Server, Access, Ingres, etc.).
Notre aide-mémoire sur les commandes MySQL offre un aperçu des commandes les plus importantes dont vous avez besoin pour maîtriser ce SGBDR.
Les conséquences de SQLi vont de légères à graves. Suite à une injection, un pirate peut :
- Corrompre, voler ou supprimer des données.
- Obtenez un accès root au système.
- Créez de nouveaux enregistrements pour ouvrir la porte à des violations plus avancées, telles qu’une attaque APT.
- Élevez les privilèges pour accéder à d’autres applications et systèmes sur le réseau.
- Compromettez le serveur ou une autre infrastructure dorsale.
- Accédez au système d’exploitation via le serveur de base de données.
L’étendue des dégâts dépend de la capacité de l’attaquant. La victime peut rencontrer n’importe quoi, de quelques erreurs de base de données à une prise de contrôle complète du serveur Web.
Comment Fonctionne L’injection SQL ?
La plupart des applications Web exigent que les utilisateurs fournissent des informations d’identification pour prouver leur identité et leur niveau d’accès. Si un utilisateur vérifié demande des données, l’application envoie une instruction SQL à la base de données sous la forme d’une requête et renvoie les données demandées.
Lorsqu’une application présente une vulnérabilité SQLi, un pirate peut ignorer le processus d’authentification et injecter manuellement des instructions SQL (ou une charge utile malveillante ) dans la base de données. La base de données ne reconnaît pas la menace et exécute l’instruction comme si l’application envoyait la requête.
Contrairement à certains types de cyberattaques, une injection SQL nécessite que le système cible ait une faille exploitable. La plupart des faiblesses proviennent d’un manque de séparation stricte entre le code du programme et les entrées fournies par l’utilisateur.
Les pirates ciblent généralement les bases de données via une application ou un site Web. Cependant, certaines attaques plus sophistiquées s’attaquent directement à la base de données.
Apprenez la différence entre SQL et NoSQL pour trouver le type de base de données parfait pour votre application.
Types D’injection SQL
Il existe deux types d’injections SQL :
- Un SQLi classique : attaques dans lesquelles un pirate envoie des commandes à la base de données et rassemble les résultats à partir de la sortie.
- Un SQLi aveugle : brèches dans lesquelles un pirate envoie des commandes à la base de données mais ne récupère pas les résultats directement à partir de la sortie.
Vous trouverez ci-dessous les sept types d’injections SQL les plus courants auxquels une entreprise peut être confrontée.
SQLi Intrabande (SQLi Classique)
Un SQLi intrabande se produit lorsqu’un pirate utilise le même canal de communication pour lancer l’attaque et recueillir les résultats. Voici un exemple de vulnérabilité d’injection intrabande dans le code WordPress :
global €wpdb ;
€title = €wpdb->get_var("select post_title from " . €wpdb->posts . " where ID=" . €_GET);
echo €titre;
Ce code a une faiblesse SQLi car l’entrée utilisateur dans €_GET va directement à la base de données. Il n’y a pas de nettoyage ou d’échappement, donc un attaquant peut envoyer des commandes directement à la base de données et recevoir la sortie vers le navigateur. Par exemple, un pirate peut envoyer :
- Commandes SELECT qui récupèrent les enregistrements de la base de données.
- Commandes INSERT qui créent de nouveaux comptes d’utilisateurs.
- Commandes UPDATE qui modifient les enregistrements existants.
Le SQLi intrabande est le type d’injection SQL le plus courant.
SQLi Basé Sur Les Erreurs
SQLi basé sur les erreurs est une technique d’injection intrabande qui s’appuie sur les messages d’erreur. Les pirates sondent à plusieurs reprises l’application à la recherche d’erreurs pour recueillir des informations sur la structure de la base de données.
Les injections SQL basées sur les erreurs permettent à un attaquant de récupérer des données telles que les noms de table et le contenu à partir d’erreurs visibles. Dans certains cas, l’injection SQL basée sur les erreurs suffit à un pirate pour énumérer une base de données entière.
SQLi Basé Sur L’union
SQLi basé sur l’union est une injection intrabande qui exploite les vulnérabilités de l’ opérateur UNION SQL.
La commande UNION exécute une ou plusieurs requêtes SELECT supplémentaires et ajoute le résultat à la requête d’origine. Un attaquant peut tirer parti des résultats étendus pour récupérer des données à partir d’autres tables de la base de données.
Le SQLi basé sur Union ne fonctionne que si les requêtes d’origine et nouvelles ont le même nombre et le même type de données de colonnes.
SQLi Inférentiel (SQLi Aveugle)
Dans un SQLi inférentiel, l’application Web ne transfère pas les données via une sortie directe. Au lieu de cela, un attaquant doit collecter des informations en envoyant des charges utiles et en observant :
- Réponse de l’application Web.
- Différences dans la page Web.
Voici un exemple de SQLi aveugle :
global €wpdb ;
€title = €wpdb->get_var("select post_title from " . €wpdb->posts . " where ID=" . €_GET);
L’entrée de l’utilisateur va directement à la base de données en concaténant la variable €_GET à la requête. Le navigateur n’affiche jamais la sortie, mais un attaquant peut recueillir des informations sur la base de données en analysant les réactions du serveur.
Ce type d’injection prend plus de temps à exploiter que SQLi en bande, mais les conséquences sont tout aussi dangereuses.
SQLi Aveugle Basé Sur Le Contenu
SQLi basé sur le contenu est une technique inférentielle dans laquelle l’attaquant force la base de données à renvoyer des résultats différents selon que la requête renvoie un résultat VRAI ou FAUX .
Voici un exemple de SQLi basé sur le contenu :
sélectionnez post_status à partir de wp_posts où ID=1 et (sélectionnez 1 dans wp_users où sous-chaîne(user_pass,1,1) = 'a' et ID=1)
Cette requête vérifie si la première lettre du mot de passe haché pour l’utilisateur avec l’ID 1 est un A. Alors que l’attaquant ne voit pas la sortie, le comportement de la page Web révèle si la requête est vraie ou non. Un pirate peut parcourir chaque caractère avec cette technique et extraire le mot de passe administrateur.
Les attaques SQLi basées sur le contenu sont lentes, en particulier sur les grandes bases de données. Un attaquant doit énumérer la base de données caractère par caractère. Un autre nom pour ce type d’attaque est l’ injection SQL aveugle basée sur les booléens .
SQLi Aveugle Basé Sur Le Temps
SQLi basé sur le temps est une autre technique d’injection inférentielle. Un attaquant envoie des requêtes qui forcent la base de données à attendre (veille) pendant un nombre spécifique de secondes avant de répondre.
Par exemple, un pirate peut demander à la base de données si la première lettre du compte admin commence par un A. Si la première lettre est A, le pirate ordonne à la base de données de se mettre en veille pendant 10 secondes. Voici à quoi ressemblerait ce code :
sélectionnez post_title à partir de wp_posts où ID = 1
union sélectionner SI(
sous-chaîne(wp_users.user_login,1,1)='a',
BENCHMARK(10000000,ENCODE('blah','asdf')),
nul)
de wp_users où ID=1
Le pirate peut ne pas voir la sortie, mais le temps de réponse pour générer une page Web révèle la réponse.
Comme SQLi basé sur le contenu, les injections basées sur le temps sont lentes. Malheureusement, ces attaques sont souvent entièrement automatisées, de sorte que des suppositions incorrectes ne ralentissent pas le processus.
SQLi Hors Bande
Le SQLi hors bande est le type d’injection le moins courant qui se produit généralement lorsqu’un pirate ne peut pas lancer une attaque directe par requête-réponse. Au lieu de cela, un pirate crée des instructions SQL qui déclenchent la base de données pour créer une connexion à un serveur externe sous le contrôle de l’attaquant.
Le serveur de base de données doit avoir la capacité de faire du DNS ou
Les attaquants choisissent généralement une approche hors bande comme alternative aux techniques basées sur le temps lorsque les réponses du serveur sont instables.
Comment Détecter L’injection SQL ?
Les tentatives SQLi apparaissent souvent comme des erreurs de base de données standard, de sorte que les injections sont difficiles à détecter sans outils. Cependant, votre équipe de sécurité doit surveiller les signes d’injections SQL.
Chaque SQLi implique des essais et des erreurs. Les pirates configurent généralement un ver ou un bot pour sonder à plusieurs reprises un site Web à la recherche de failles. Configurez vos outils d’analyse pour surveiller les échecs de connexion et les mauvaises erreurs de syntaxe.
Voici d’autres moyens de détecter les injections SQL :
- Examinez l’événement error_reported pour les erreurs impaires.
- Recherchez dans la base de données les balises HTML courantes, telles que
- Surveillez le trafic pour détecter les changements de comportement suspects, en particulier les changements d’autorisations et de mots de passe.
- Configurez un système de détection d’intrusion (IDS) basé sur le réseau pour surveiller les connexions au serveur de base de données.
- Configurez un IDS basé sur l’hôte pour surveiller les journaux du serveur Web.
Utilisez des outils d’évaluation des vulnérabilités pour vous assurer que votre application est à l’abri de SQLi et des cyberattaques similaires.
Comment Prévenir Les Attaques Par Injection SQL ?
Il existe plusieurs mesures efficaces qu’une entreprise peut prendre pour prévenir les attaques SQLi.
Désinfecter L’entrée
Le nettoyage des entrées (ou validation) consiste à vérifier et à filtrer les entrées des utilisateurs. Cette technique garantit que l’application peut identifier les entrées utilisateur illégitimes et les exécutables dangereux.
Les développeurs peuvent nettoyer les entrées de trois manières :
- Nettoyage de la liste blanche : seuls les caractères et les chaînes de code pré-approuvés peuvent accéder à la base de données.
- Nettoyage de la liste noire : les développeurs interdisent à certains caractères d’atteindre la base de données (sauts de ligne, espaces blancs supplémentaires, balises, tabulations, etc.).
- Nettoyage d’ échappement : toutes les données des requêtes nécessitent un échappement SQL avant l’exécution de la requête.
En règle générale, la liste blanche est une option plus simple et plus sécurisée que la liste noire. Un pirate intelligent peut trouver un moyen de contourner une liste noire, alors vérifiez si possible l’entrée de l’utilisateur avec des listes blanches.
Une autre bonne pratique consiste à valider les entrées de l’utilisateur avec des menus déroulants et des boutons radio. Ces champs de saisie empêchent les utilisateurs de saisir des données et arrêtent l’injection de code exécutable.
Code SQL Paramétré
Les requêtes paramétrées exigent que les développeurs définissent d’abord tout le code SQL et transmettent ensuite chaque paramètre à la requête. Ce style de codage permet à la base de données de faire la différence entre le code et les données, une fonctionnalité qui n’est pas possible avec les requêtes SQL dynamiques.
Le code SQL paramétré empêche les attaquants de modifier l’intention d’une requête même s’ils insèrent des commandes. Par exemple, si un pirate saisit l’ID utilisateur ‘1’=’1 , la requête recherchera un nom d’utilisateur correspondant à l’intégralité de la chaîne ‘1’=’1 . La base de données n’accepterait pas la requête en tant que commande.
Limiter Les Autorisations Des Utilisateurs
Utilisez la sécurité Zero Trust et limitez les utilisateurs aux autorisations minimales dont ils ont besoin pour remplir leurs rôles. Moins il y a de comptes avec des autorisations de lecture-écriture-exécution, mieux c’est.
Par exemple, si un site Web renvoie uniquement le contenu de la base de données avec l’ instruction SELECT , n’accordez pas d’autres privilèges à la connexion, tels que INSERT , UPDATE ou DELETE .
Une autre bonne pratique consiste à se méfier de toutes les entrées des utilisateurs. Traitez les entrées des utilisateurs internes de la même manière que les entrées provenant de sources externes et tierces. De plus, n’autorisez jamais l’application Web à se connecter à la base de données avec des privilèges d’administrateur.
Configurer Un Pare-feu
Utilisez un pare-feu d’application Web (WAF) pour filtrer tout le trafic entre les applications Web et votre base de données. Un pare-feu protège toutes les applications Web, alors configurez les défenses pour arrêter SQLi et les cyberattaques similaires.
Découvrez les différents types de pare-feu et trouvez celui qui offre la protection idéale à votre entreprise.
Mises à Jour Et Correctifs
Maintenez tous les systèmes et défenses à jour avec les derniers correctifs et mises à jour. Cela aide :
- Attrapez de nouveaux bogues qui permettent une injection SQL.
- Empêchez les attaquants d’exploiter les faiblesses et les bogues présents dans les anciennes versions du logiciel.
Corrigez régulièrement tous les composants logiciels d’application Web, y compris les bibliothèques, les plug-ins, les frameworks, le serveur Web et le serveur de base de données.
Tests Réguliers
Exécutez des tests de sécurité pour vérifier la résilience de votre base de données et des applications associées. Des tests réguliers sont essentiels pour découvrir les vulnérabilités de toutes les cyberattaques. Envisagez d’exécuter :
- Tests d’analyse dynamique (DAST) qui examinent l’application du point de vue de l’attaquant.
- Tests d’analyse statique (SAST) qui recherchent les vulnérabilités au niveau du code.
Des tests manuels sur les points d’entrée potentiels dans l’application permettent également de détecter les vulnérabilités SQLi. Voici plusieurs tests à considérer :
- Soumettez des guillemets simples et inspectez les réponses de la base de données.
- Exécutez des conditions booléennes (OR 1=1, OR 1=2, etc.) et recherchez les différences dans les réponses.
- Soumettez des charges utiles qui déclenchent des retards lors de l’exécution. Mesurez les différences dans les temps de réponse.
- Exécutez des charges utiles OAST qui déclenchent une interaction réseau hors bande. Surveillez les interactions résultantes pour les exploits potentiels.
Découvrez les tests d’intrusion, le formulaire de test le plus complet et le plus réaliste du marché.
Ne Stockez Jamais De Données Sensibles En Texte Brut
Chiffrez toutes les données privées et confidentielles de votre base de données. Le chiffrement offre également un niveau de protection supplémentaire si un attaquant parvient à exfiltrer des données sensibles.
Ne Pas Afficher Les Erreurs De Base De Données Aux Utilisateurs
Les messages d’erreur de base de données ne doivent jamais s’afficher sur le navigateur Web du client. Un attaquant peut utiliser les détails techniques des messages d’erreur pour ajuster les requêtes pour une injection réussie.
Au lieu d’afficher des messages d’erreur avec des informations utiles, configurez des messages d’erreur simples basés sur des mots qui s’excusent pour la gêne occasionnée.
Former Et Maintenir La Sensibilisation à SQLi
La prévention des injections SQL est un travail d’équipe et tous les membres du personnel doivent connaître l’importance de la cybersécurité. Fournir une formation de sécurité appropriée à tous les développeurs, au personnel d’assurance qualité, aux administrateurs système et aux DevOps.
Bien Que Dangereuses, Les Attaques SQLi Sont Faciles à Prévenir
Bien que les injections SQL puissent être dommageables, une entreprise bien organisée ne devrait jamais être victime de ces attaques. Mettez en place les précautions appropriées et assurez-vous que vos bases de données résistent aux injections SQL.
