Le développement rapide des nouvelles technologies a donné aux entreprises non seulement un avantage concurrentiel et un gain de rentabilité, mais aussi un sérieux casse-tête en matière de cybersécurité. De nos jours, les pirates peuvent mener des attaques à la fois manuelles et automatisées, qui deviennent chaque jour plus sophistiquées. La chose surprenante est que bien que certaines des vulnérabilités logicielles les plus populaires soient bien connues et facilement détectables, elles sont toujours activement exploitées.
Pour exemple, l’injection SQL a été découverte pour la première fois en 1998, mais elle reste toujours le principal risque de sécurité dans les applications web, selon OWASP. De plus, les injections SQL, ainsi que la force brute et l’utilisation d’identifiants volés, représentent un stupéfiant 80 % des violations de données dans le monde.
Compte tenu de la prévalence de cette vulnérabilité web, nous avons compilé un guide complet sur les injections SQL, abordant les questions suivantes :
Dans cet article, nous aborderons :
Qu’est-ce que l’injection SQL ?
Avant de passer directement à la définition de l’injection SQL, parlons d’abord de SQL lui-même. SQL (Structured Query Language) est un langage de programmation utilisé pour accéder aux bases de données et les manipuler.
SQL est utilisé par certains des systèmes de gestion de bases de données les plus populaires, tels que MySQL et Microsoft SQL.
L’injection SQL (SQLi) est une cyberattaque qui cible les sites web et les applications web utilisant des bases de données SQL. C’est une technique d’injection de code qui repose sur l’insertion d’instructions SQL malveillantes via une saisie web. En d’autres termes, un acteur malveillant ou le « méchant » essaie une gamme de commandes SQL pour manipuler la base de données et obtenir une réponse qui révélera, espère-t-il, des données sensibles.
En cas d’injection SQL réussie, le pirate peut effectuer l’une des actions suivantes :
- Contourner l’authentification
- Voler l’identité d’un utilisateur, y compris d’un cadre dirigeant
- Récupérer, ajouter, modifier ou détruire complètement des enregistrements dans la base de données
- Devenir administrateur
- Effectuer d’autres comportements manipulateurs
Les injections SQL sont si courantes en raison de la prévalence des sites web utilisant des bases de données SQL et d’une mise en œuvre relativement facile.
Peu coûteuse
Facile à exécuter
Grande attractivité de la cible (données sensibles et de grande valeur)
des infrastructures de bases de données partagées = plusieurs applications affectées simultanément
Comment fonctionne l’injection SQL ?
Les injections SQL sont possibles lorsqu’un site web ou une application web ne dispose pas d’un processus adéquat d’assainissement des entrées. En termes simples, l’assainissement des entrées empêche les pirates d’utiliser des caractères spéciaux pour injecter du code malveillant dans le champ de saisie de données.
Une requête SQL légitime n’est qu’une interaction entre l’utilisateur et la base de données. Par exemple, en saisissant un nom d’utilisateur et un mot de passe, l’utilisateur demande l’accès au logiciel. Si certains des caractères saisis ne correspondent pas aux identifiants stockés sur le serveur, l’accès est refusé.
Cependant, si les développeurs ont été négligents et n’ont pas mis en place un assainissement robuste des entrées, le pirate peut utiliser des formulaires de saisie pour envoyer ses propres requêtes à la base de données en saisissant des chaînes de code SQL exécutable.
Avant de montrer comment effectuer une injection SQL, passons d’abord en revue les types d’injection SQL pour mieux comprendre les principes qui rendent cette attaque web possible.
Types d’injection SQL
En fonction de l’intention de l’acteur malveillant et des contrôles de sécurité du système, différentes techniques d’injection SQL sont appliquées. Passons en revue quelques-uns des types d’injection SQL les plus courants pour être conscient des scénarios qui donnent le feu vert aux pirates.
Injections SQL classiques
L’injection SQL classique, également connue sous le nom d’in-band, repose sur un seul canal de communication pour à la fois effectuer l’attaque et collecter les données. Elle est considérée comme la plus facile à mettre en œuvre, et elle peut exfiltrer des données via :
- Messages d’erreur. Dans ce cas, le pirate saisit délibérément une entrée qui entraînera une erreur pour obtenir des informations sur la structure de la base de données. Vous avez certainement déjà vu ces messages d’erreur déroutants qui n’ont aucune valeur pour les utilisateurs finaux mais qui contiennent des détails techniques vitaux — exactement ce que les pirates espèrent récupérer.
- Opérateurs UNION. Les pirates peuvent utiliser le mot-clé UNION pour étendre leur requête originale en combinant deux ou plusieurs instructions SELECT. Ce type d’attaque permet d’effectuer des requêtes entre tables.
Injections SQL en aveugle
Ce type d’injection demande plus de patience de la part du pirate car aucune donnée n’est affichée sur la page web et l’énumération de la base de données se fait caractère par caractère. Il s’applique lorsque la base de données n’affiche que des messages d’erreur génériques mais que le code peut encore être vulnérable. Les injections SQL en aveugle nécessitent des techniques de force brute et d’innombrables requêtes ; cependant, ce processus peut également être automatisé grâce à des outils comme SQLMap. Les injections SQL en aveugle se subdivisent en :
- Basées sur le contenu. L’agent malveillant pose une série de questions vrai ou faux et détermine si l’instruction était vraie ou fausse en fonction de la différence dans la réponse de l’application.
- Basées sur le temps. Le pirate utilise différentes fonctions temporelles des bases de données SQL pour déterminer quel type de base de données est utilisé, car différentes bases de données utilisent différentes fonctions pour les mêmes opérations. De plus, en utilisant sleep ou des commandes SQL similaires, ils peuvent facilement identifier si la requête est vraie ou fausse : réponse immédiate — faux ; la base de données répond avec le délai mentionné — vrai.
Injections SQL hors bande
Ce type d’injection SQL est moins courant car il dépend de la capacité du serveur à créer des requêtes DNS ou HTTP pour transmettre des données au pirate. Ces fonctionnalités peuvent ne pas être activées sur tous les serveurs de base de données d’applications, ce qui limite le taux de succès de cette entreprise malveillante.
Les injections SQL hors bande sont ainsi nommées parce que le pirate ne peut pas utiliser le même canal pour mener une attaque. Par exemple, lorsque la réponse du serveur est trop lente ou instable, il devient difficile de travailler avec des SQLi par inférence.
de la vulnérabilité
mondial
Exemple d’attaque par injection SQL
Bien qu’il soit toujours judicieux de s’équiper de connaissances théoriques, il est encore plus bénéfique d’acquérir une expertise pratique sur le sujet étudié.
Sans plus attarder, examinons les bases qui peuvent vous aider à mieux comprendre comment effectuer une injection SQL.
Exemples de code SQLi
Les types de SQLi sont effectivement nombreux ; cependant, les plus simples et les plus populaires tournent autour des manipulations avec les instructions UPDATE, INSERT et SELECT ainsi que les clauses WHERE et ORDER BY.
Les exemples ci-dessous couvrent les bases et ne sont possibles que s’il n’y a aucun contrôle de sécurité contre l’insertion de syntaxe dangereuse dans les champs de saisie.
Récupération de données avec la clause WHERE
Supposons que vous naviguiez sur un site de commerce électronique et que vous vous soyez arrêté sur la section Accessoires. Une URL typique dans ce cas ressemblerait à quelque chose comme :
https://e-commerce-website.com/products?category=Accessories
Ce qui se passe en coulisses ressemble à ceci :
SELECT * FROM products WHERE category = 'Accessories' AND released = 1
Ici, l’application web effectue une requête SQL à la base de données pour n’afficher que les accessoires disponibles à l’utilisateur final. Cette requête peut être facilement modifiée en insérant une syntaxe SQL « intelligente » comme des doubles tirets pour commenter une partie de la requête et la rendre ainsi non pertinente.
https://insecure-website.com/products?category=Accessories’––
Voici le code SQL pour la même requête :
SELECT * FROM products WHERE category = 'Accessories'--' AND released = 1Dans ce cas, le pirate peut également voir tous les articles non publiés car la restriction released=1 est désactivée.
La vulnérabilité peut être davantage exploitée en ajoutant des entrées toujours vraies, comme OR 1=1.
https://insecure-website.com/products?category=Accessories’+OR+1=1––
Ce que la base de données reçoit est le suivant :
SELECT * FROM products WHERE category = 'Accessories' OR 1=1--' AND released = 1Dans le cas ci-dessus, la base de données retournera tous les articles, à la fois publiés et non publiés, de toutes les autres catégories.
Se connecter sans identifiants
Un autre cas d’utilisation de la syntaxe intelligente consiste à accéder à une application en n’ayant qu’un nom d’utilisateur à disposition. La stratégie est la même : utiliser la séquence de doubles tirets pour mettre en commentaire une partie du code.
Voici le code SQL de base qui rend la connexion utilisateur possible :
SELECT * FROM users WHERE username = 'john' AND password = 'johndoe123'Voici la version injectée de la même requête :
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''Si le pirate suppose que le nom d’utilisateur est « administrator » ou « admin », ce qui peut encore être le cas, et utilise l’indicateur de commentaire SQL avant la partie mot de passe de la requête, il peut se connecter en tant qu’administrateur réel ou en tant qu’utilisateur ayant ce nom d’utilisateur.
Ce qui est encore plus choquant, c’est que dans certains cas, même le nom d’utilisateur n’est pas nécessaire.
SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""=""En trompant l’application avec des instructions toujours vraies, comme une chaîne vide est toujours égale à une autre chaîne vide, le pirate peut se connecter avec succès sans aucun identifiant.
Maximiser les gains
Si une SQLi initiale a réussi et que l’application répond avec les données réelles de la table ciblée, c’est une opportunité que les pirates ne peuvent pas se permettre de manquer. Très probablement, ils procéderont à une attaque UNION.
Les pirates peuvent exploiter les capacités du mot-clé UNION, comme l’exécution d’une ou plusieurs requêtes SELECT supplémentaires et l’ajout des résultats à la requête originale, pour accéder aux données d’autres tables.
Une attaque UNION nécessite certaines connaissances sur la structure de la base de données et d’autres prérequis à satisfaire. Cependant, si nous supposons qu’un acteur malveillant connaît le nombre de colonnes que la requête originale retourne, le type de données qu’elles peuvent contenir, le nom de la table et ses colonnes, il peut passer de ceci
SELECT name, description FROM products WHERE category = 'Accessories'à ceci
' UNION SELECT username, password FROM users--,ce qui lui permettra de récupérer non seulement les produits et leurs descriptions, mais aussi les noms d’utilisateur et mots de passe correspondants.
Exemples réels de SQLi
Pour prouver que nous n’exagérons pas la véritable menace des SQLi, nous avons compilé une liste d’attaques SQLi assez récentes et des lourdes pertes que les entreprises victimes ont subies ou auraient pu subir sans l’intervention de hackers éthiques.
3,7 millions de mots de passe hachés divulgués
Astuce Google simple pour trouver les vulnérabilités de base de données
Vous vous demandez peut-être aussi comment les pirates savent quel site web (parmi presque 2 milliards) cibler pour augmenter leurs chances d’une attaque SQLi réussie. Eh bien, il existe une technique spéciale connue sous le nom de Google hacking ou Google dorking. Cette dernière est utilisée pour récupérer toutes sortes d’informations sensibles — des adresses e-mail et des détails de cartes de paiement aux serveurs vulnérables et aux caméras internet exposées.
Le Google hacking est né en 2002 lorsque Johnny Long, un expert reconnu en sécurité informatique, a décidé de documenter des requêtes de recherche Google avancées qui révélaient des systèmes vulnérables ou des informations sensibles. Au fil des années, la liste initiale de Google Dorks, en d’autres termes des chaînes de recherche avancées, a grandi pour former une base de données entière, maintenant maintenue par Offensive Security.
L’utilisation du Google hacking pour trouver des SQLi n’est qu’un petit sous-ensemble de ce que vous pouvez faire avec cette technique de recherche avancée. Et voici comment vous pouvez le faire.
Disons que nous allons sur Google et tapons quelque chose comme :
site:com inurl:id "You have an error in your SQL syntax"Cette requête demande au moteur de recherche d’explorer tous les sites web en .com qui ont des erreurs de syntaxe dans leur code SQL. Ces erreurs de syntaxe sont probablement des injections délibérément placées.
Une autre chose à garder à l’esprit est que Google n’est pas le seul moteur prenant en charge la recherche avancée. Vous pouvez obtenir les mêmes résultats avec Bing, Yahoo ou DuckDuckGo ; la seule différence réside dans la syntaxe des opérateurs de recherche qui diffère légèrement selon les moteurs.
Comment prévenir l’injection SQL ?
Après avoir assimilé toutes ces informations effrayantes sur les dangers des SQLi, la question raisonnable qui vous vient à l’esprit est de savoir comment prévenir l’injection SQL. Parce que cette attaque existe depuis un certain temps, les experts en sécurité ont appris à la combattre et à protéger les applications web contre différents types de SQLi.
Bien que chaque cas soit unique et nécessite une investigation professionnelle de la part de consultants en sécurité et de pentesters, ces meilleures pratiques de sécurité feront l’affaire pour la plupart des organisations et réduiront considérablement le risque de SQLi.
Voici quelques-unes des techniques de prévention des injections SQL bien connues qui fonctionnent réellement.
Refactoriser le code hérité
Les logiciels hérités sont connus pour causer une série de problèmes, la sécurité étant l’un des plus néfastes.
La raison pour laquelle les applications héritées sont des cibles faciles pour les pirates est leur incapacité à intégrer des contrôles de sécurité efficaces en raison d’incompatibilités ou d’autres limitations techniques. Par conséquent, si l’application ne peut pas être entièrement réécrite et migrée vers la pile moderne, au moins une refactorisation partielle des modules les plus vulnérables devrait être envisagée.
Utiliser la validation des entrées côté serveur
Toute saisie de données nécessite une validation pour que l’utilisateur puisse accéder ou effectuer d’autres actions. La validation côté client est souvent considérée comme une vérification initiale rapide dans le navigateur permettant à l’utilisateur de remarquer rapidement les erreurs de saisie. Qu’elle soit intégrée en HTML5 ou personnalisée avec Javascript, la validation côté client est facile à contourner et est considérée comme non sécurisée et peu fiable.
Par conséquent, une validation robuste des entrées ne peut être effectuée que côté serveur. De plus, la validation des entrées côté serveur se subdivise davantage en liste d’autorisation ou positive et liste de blocage ou négative. La première est considérée comme plus efficace pour combattre les SQLi.
Voici comment fonctionne la validation des entrées côté serveur par liste d’autorisation : le serveur n’accepte que les données qui ont été définies comme bonnes et acceptables. Par exemple, la vérification des détails du numéro de carte de crédit peut impliquer des étapes telles que la vérification du nombre attendu de chiffres, uniquement des entrées numériques, et le passage de la formule de Luhn.
De plus, la validation côté serveur doit être effectuée à la fois aux niveaux syntaxique (exactitude des dates, symboles monétaires) et sémantique (validation des entrées en relation avec le contexte métier).
Même si la mise en liste d’autorisation peut être assez complète, la validation des entrées côté serveur ne doit pas être considérée comme la principale mesure de sécurité contre les SQLi, mais plutôt comme une étape supplémentaire dans le programme de sécurité multicouche.
Restreindre les privilèges des utilisateurs de base de données
Le principe du moindre privilège (POLP) est bien connu dans le domaine de la sécurité de l’information. Et c’est assez simple : limiter l’accès à la base de données en fonction des rôles individuels des utilisateurs et de leurs fonctions quotidiennes.
Généralement, seul un nombre limité de personnes a besoin de créer ou de supprimer quelque chose dans la base de données. Par conséquent, il est vital de s’assurer que la majorité des utilisateurs n’ont que l’accès en lecture et des vues partielles des tables strictement nécessaires à leurs opérations.
Un autre facteur crucial à garder à l’esprit est que vous devez changer les privilèges par défaut du SGBD en mode restreint, ce qui n’accordera pas au pirate un contrôle complet sur le système même en cas d’attaque SQLi réussie.
Dans le cas de plusieurs applications utilisant la même base de données, chaque application nécessite un compte d’utilisateur de base de données séparé avec des droits d’accès distincts. Cette approche aide également à minimiser les dommages causés par des SQLi potentielles.
En résumé, pour éviter l’effet boule de neige lorsque le pirate obtient les droits root via SQLi, rendez votre politique d’accès aussi granulaire que possible.
Utiliser des instructions préparées avec des requêtes paramétrées
Selon OWASP, l’utilisation d’instructions préparées avec des requêtes paramétrées est la principale défense contre les SQLi. Les instructions préparées sont si efficaces contre les SQLi parce qu’elles permettent à la base de données de distinguer clairement entre le code et l’entrée fournie par l’utilisateur.
Une instruction préparée typique suivra un algorithme simple :
- un modèle d’instruction SQL est créé et envoyé à la base de données
- la requête SQL subit une analyse syntaxique et sémantique
- la requête SQL est compilée avec du texte de remplacement (liaison)
- les espaces réservés sont remplacés par l’entrée fournie par l’utilisateur
- la requête est stockée dans le cache
- la base de données exécute l’instruction
Comme on le voit dans ces étapes, les données fournies par l’utilisateur ne peuvent pas affecter l’intention d’une requête car elles sont séparées du code exécutable et seront toujours interprétées comme une simple chaîne.
Une autre question se pose ici : si les instructions préparées sont si sécurisées, pourquoi avons-nous encore tant d’incidents SQLi ? Le fait est que, dans certains cas, les instructions préparées peuvent avoir un impact négatif sur les performances de l’application, c’est pourquoi les développeurs choisissent de ne pas les utiliser et ont recours à d’autres techniques de sécurité moins efficaces.
Implémenter les procédures stockées correctement
Une procédure stockée est un code SQL préparé qui peut être sauvegardé et utilisé plusieurs fois à l’avenir. La différence entre une procédure stockée et une instruction préparée est que le code SQL de la première est défini et stocké dans la base de données elle-même : lorsque la requête doit être exécutée, elle est simplement appelée depuis l’application.
Les procédures stockées sont considérées comme aussi efficaces que les instructions préparées à condition d’être implémentées de manière sécurisée. Sinon, elles sont également vulnérables aux SQLi.
Les développeurs doivent faire attention à ne pas inclure de SQL dynamique non sécurisé dans la procédure stockée. Si la génération d’un SQL dynamique dans une procédure stockée est totalement inévitable, nous conseillons de paramétrer les requêtes à l’intérieur de la procédure stockée au lieu de concaténer les paramètres.
Échapper toutes les entrées fournies par l’utilisateur
Cette approche est un remède assez désespéré : elle ne doit être utilisée que si rien d’autre n’est faisable. Un cas d’utilisation typique serait la protection de logiciels hérités avec un budget limité pour une validation complète des entrées.
Voici comment fonctionne l’échappement : la fonction d’échappement encode les caractères spéciaux, tels que « / », « ? », « $ », pour que la base de données ne confonde pas l’entrée fournie par l’utilisateur avec le code du développeur.
Bien que chaque SGBD ait son propre schéma d’échappement, l’objectif est le même — empêcher que l’entrée fournie par l’utilisateur soit interprétée comme une commande exécutable.
Une fois de plus, cette technique ne peut pas garantir une protection à 100 % contre les SQLi. Idéalement, l’application devrait être réécrite de zéro en utilisant des requêtes paramétrées ou des procédures stockées.
Une autre méthode d’échappement consiste à encoder en hexadécimal toutes les entrées fournies par l’utilisateur. Ce scénario présuppose l’encodage non seulement des caractères spéciaux, mais de chaque caractère de l’entrée avant de l’inclure dans la requête SQL.
Masquer les erreurs de base de données
Ce qui a causé l’erreur de base de données est très utile pour le développeur mais pas pour l’utilisateur final. Il est vital de s’assurer que les messages d’erreur ne divulguent aucune information sensible qu’un pirate pourrait utiliser.
Par exemple, au lieu d’afficher l’instruction SQL révélant exactement où l’erreur s’est produite, affichez des fenêtres contextuelles génériques orientées client, comme « Désolé, nous rencontrons des problèmes techniques. Veuillez réessayer plus tard. »
Chiffrer les données sensibles
Laisser des données hautement confidentielles en texte clair n’est jamais une bonne idée. C’est pourquoi tant d’entreprises, notamment dans les secteurs fintech, santé et médias, ont intégré le chiffrement des données dans leurs systèmes — le coût de l’exposition des données est tout simplement trop élevé (environ 4 millions USD en moyenne).
Un autre facteur critique à garder à l’esprit est que le chiffrement seul n’est pas une solution miracle. Supposons qu’une entreprise ait mis en place le hachage des mots de passe, ce qui signifie que les mots de passe réels ne sont jamais stockés, seulement leurs équivalents hachés. Cependant, si les utilisateurs n’ont pas pris la peine de créer des mots de passe forts, ce qui est souvent le cas, leurs identifiants peuvent être facilement compromis avec des tables de hachage ou arc-en-ciel qui peuvent mapper les clés aux valeurs.
Le salage des hachages chiffrés fournirait une couche de sécurité supplémentaire. En termes simples, le salage consiste à ajouter une donnée aléatoire au mot de passe avant qu’il ne soit haché. Les mots de passe salés réduisent la probabilité que les mots de passe faibles des utilisateurs se trouvent dans une table de hachage.
Effectuer des inspections régulières du code
Les SQLi sont souvent le résultat de mauvaises pratiques de développement logiciel. Par conséquent, il est raisonnable de commencer le plan de prévention à partir du code source en laissant des experts en sécurité tiers effectuer un audit de code impartial.
Il est tout aussi important de mener des tests de pénétration réguliers pour repérer les signaux d’alarme et détecter les vulnérabilités négligées par les scanners et les fuzzers. Pour un testeur de pénétration compétent, découvrir une vulnérabilité SQLi est une tâche facile ; de plus, ils peuvent expliquer le résultat d’autres exploits potentiels ou existants et proposer un plan de remédiation contre les injections SQL adapté au statu quo de l’entreprise.
Résumé
L’injection SQL est une vulnérabilité si ancienne qu’il est honteux de savoir qu’elle constitue encore une menace pour les sites web et applications modernes. Elle est très populaire en raison de sa mise en œuvre relativement facile, de la prévalence des SGBD SQL et de la valeur immense des données métier. La bonne nouvelle — elle est évitable. Il suffit d’aligner vos efforts d’ingénierie sur les dernières pratiques de sécurité, de surveiller et d’inspecter en continu, et de réaliser des tests d’injection SQL indépendants pour combler les lacunes restantes.
Quelle est votre expérience dans la lutte contre les SQLi ? Nous aimerions le savoir ; partagez via e-mail ou dans les commentaires !
Prévenu, c’est à moitié guéri : la feuille de triche ultime
pour la prévention des SQLi
