Injection SQL (SQLi)

Qu’est-ce que l’injection SQL ?

L’ injection SQL (SQLi) est une vulnérabilité qui permet à un pirate malveillant d’introduire (d’injecter) du code SQL indésirable dans les requêtes SQL exécutées par le logiciel.

Gravité:		très sévère
Prévalence:		découvert souvent
Portée:		peut apparaître dans un logiciel qui utilise SQL
Impact technique :		accès à la base de données ou aux informations système
Conséquences dans le pire des cas :		compromis complet du système
Solution rapide:		utiliser des instructions préparées également appelées requêtes paramétrées

Comment fonctionne l’injection SQL ?

Si une application utilise une base de données externe, elle doit créer des requêtes dans cette base de données et récupérer les résultats. La plupart des applications utilisent des bases de données relationnelles prenant en charge SQL (Structured Query Language). Il s’agit d’un langage textuel conçu pour être simple et facile à comprendre par les humains. Les bases de données populaires prenant en charge SQL incluent Oracle, Microsoft SQL Server (MSSQL), MySQL, PostgreSQL, etc.

Les requêtes aux bases de données sont rarement statiques – les informations que l’application doit obtenir de la base de données ou y stocker dépendent généralement des données fournies par l’utilisateur. L’entrée de l’utilisateur se présente généralement sous la forme d’un texte simple, tout comme la syntaxe SQL elle-même, de sorte que les développeurs créent souvent des requêtes en concaténant directement les données fournies par l’utilisateur avec des instructions SQL. Par exemple, renvoie le prénom et le nom de l’utilisateur en fonction de l’ID fourni par l’utilisateur.SELECT first_name,last_name FROM users WHERE user_id = 'id_supplied_by_the_user'

S’il n’y a pas de validation d’entrée, un pirate malveillant peut utiliser des formulaires de saisie de page Web ou des requêtes HTTP directes pour fournir une charge utile contenant des instructions SQL. Si l’application concatène simplement ces données utilisateur avec des commandes statiques, l’attaquant est souvent en mesure de modifier complètement la syntaxe et le fonctionnement de la requête d’origine. Ils peuvent utiliser des caractères spéciaux tels que des guillemets simples ou des points-virgules pour ajouter des commandes et/ou ignorer les commandes statiques. Le code malveillant résultant peut même permettre à l’attaquant d’exécuter des commandes telles que DROP (supprimer une table de base de données ou même la base de données entière). C’est ce qu’on appelle une injection SQL.

Les injections SQL peuvent se produire dans n’importe quel logiciel qui communique avec des bases de données SQL. Ils sont les plus répandus dans la sécurité des applications Web car les applications Web utilisent très souvent des serveurs SQL principaux. Cependant, ils peuvent également se produire dans d’autres types d’applications et de systèmes. 

Les injections SQL sont considérées comme l’une des plus anciennes vulnérabilités connues – elles ont été documentées pour la première fois en 1998. Elles sont classées comme CWE-89 : Neutralisation incorrecte d’éléments spéciaux utilisés dans une commande SQL et sont incluses dans la catégorie OWASP Top 10 A3:2021 (Injection) .

Un exemple simple d’injection SQL

Voyons ce qu’un attaquant peut faire avec l’exemple d’authentification simple suivant :

SELECT * FROM users WHERE user_id = 'id_supplied_by_the_user' AND password = 'password_supplied_by_the_user'

Cette simple instruction SELECT renvoie toutes les données utilisateur pertinentes s’il existe un enregistrement d’ID et de mot de passe correspondant dans la base de données. Cela signifie que si l’utilisateur fournit un ID et un mot de passe valides, la requête peut renvoyer le prénom et le nom d’un utilisateur (selon le schéma de la table des utilisateurs ). Si l’utilisateur fournit un ID et/ou un mot de passe non valide, la requête renvoie un ensemble de données vide. Un développeur peut utiliser cette requête simple pour vérifier si l’utilisateur peut se connecter.

Un pirate informatique malveillant peut fournir la valeur id_supplied_by_the_user suivante :

admin'--

En conséquence, la chaîne de requête envoyée à la base de données deviendra :

SELECT * FROM users WHERE user_id = 'admin'--' AND password = ''

Le guillemet simple complète l’affectation de user_id et le double tiret (–) fait que le reste de l’instruction SQL (c’est-à-dire la vérification du mot de passe) est traité comme un commentaire. Par conséquent, l’application exécute la requête suivante :

SELECT * FROM users WHERE user_id = 'admin'

Si elle est exécutée, cette requête représente une injection SQL réussie. Il renvoie toutes les données utilisateur pour admin , permettant potentiellement au pirate malveillant d’obtenir un accès non autorisé à l’application en tant qu’administrateur.

Types de vulnérabilités d’injection SQL

Il existe 5 techniques d’injection SQL principales. Chacun d’eux est décrit en détail dans une section distincte de ce guide :

• SQLi intrabande (basé sur les erreurs et sur la sélection d’union)
• SQLi inférentiel/aveugle (basé sur les booléens et sur le temps)
• SQLi hors bande

Conséquences potentielles d’une attaque par injection SQL

L’injection SQL est l’une des vulnérabilités les plus graves pour deux raisons. Tout d’abord, les bases de données auxquelles accèdent les applications Web contiennent souvent des informations hautement sensibles de grande valeur pour les attaquants. Par conséquent, les attaquants sont très intéressés à mettre la main sur ces données. 

Deuxièmement, l’exploitation des injections SQL en combinaison avec d’autres vulnérabilités courantes peut avoir des conséquences dramatiques. Il est même possible d’ obtenir un accès au système d’exploitation via une injection SQL , ouvrant la voie à une prise en main complète du système.

Les conséquences typiques des injections SQL incluent :

• Accès aux données sensibles stockées dans la base de données, telles que les mots de passe et/ou les numéros de carte de crédit
• Accès aux informations sur la base de données et le système d’exploitation pour faciliter d’autres attaques

Si l’attaquant est capable d’utiliser l’élévation de privilèges (élévation de privilèges) pour obtenir l’accès au système d’exploitation, puis l’accès root, il peut poursuivre avec l’un des types d’attaques courants suivants :

• Ransomware ou autre malware : l’attaquant peut installer un agent de ransomware sur la machine. Le logiciel malveillant utilisera alors d’autres méthodes pour se propager à d’autres actifs appartenant à la victime, paralysant potentiellement des réseaux d’entreprise entiers.
• Extraction de crypto-monnaie : les attaquants installent souvent des mineurs de crypto-monnaie sur des machines compromises. L’exploitation minière consomme vos ressources informatiques pour fournir aux cybercriminels un financement pour des activités plus malveillantes.
• Accès à d’autres systèmes : même si le système actuel est de faible importance, il peut permettre à l’attaquant de cibler plus facilement des systèmes hautement prioritaires.

Exemples de vulnérabilités d’injection SQL connues

• 2021 : GabLeaks – la plateforme de médias sociaux d’extrême droite Gab a été attaquée à l’aide d’une injection SQL qui a permis aux attaquants d’obtenir 70 gigaoctets de données.
• 2020 : Sophos XG Firewall – l’une des sociétés de sécurité les plus renommées au monde a trouvé une injection SQL dans son produit parce que des pirates malveillants l’utilisaient pour attaquer leurs clients.
• 2019 : Service de TVA bulgare – à la suite d’une attaque par injection SQL, enregistrements contenant les données fiscales de 5 millions de citoyens sur une période de 10 ans, y compris les noms complets, les informations sur les revenus, les numéros d’identification personnels (EGN), le statut d’emploi, les avantages sociaux , et l’assurance médicale, sont devenus accessibles via des forums clandestins.
• 2014 : 420 000 sites Web attaqués par un gang russe – à l’aide de botnets et d’injections SQL courantes, les cybercriminels ont pu collecter 1,2 milliard d’informations d’identification sur environ 420 000 sites Web et applications Web publics.

Comment détecter les vulnérabilités d’injection SQL ?

La meilleure façon de détecter les vulnérabilités SQLi varie selon qu’elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, il peut suffire d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est sensible à SQLi, vous pouvez supposer que votre logiciel est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) pour les applications Web ou un analyseur de réseau pour les systèmes et applications en réseau.Si vous développez votre propre logiciel ou si vous souhaitez avoir la possibilité de trouver des vulnérabilités SQLi jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité SQLi pour être certain qu’elle existe. Cela nécessite soit d’effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité, soit d’utiliser un outil d’analyse des vulnérabilités qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités d’injection SQL dans les applications Web ?

Le seul moyen totalement efficace de prévenir les vulnérabilités SQLi dans les applications Web consiste à utiliser des requêtes paramétrées (également appelées instructions préparées) pour accéder aux bases de données SQL. Les requêtes paramétrées sont disponibles dans presque tous les langages de programmation courants . Ils vous permettent d’éviter la concaténation de chaînes et de transmettre à la place des paramètres en toute sécurité aux requêtes SQL. Si votre langage de programmation ne prend pas en charge les requêtes paramétrées mais que votre moteur de base de données prend en charge les procédures stockées, vous pouvez utiliser à la place des procédures stockées avec des instructions préparées.

Il n’est pas recommandé de se fier uniquement à d’autres méthodes de prévention telles que les listes blanches, les listes noires ou le filtrage/l’échappement des entrées. Les pirates malveillants peuvent trouver un moyen de contourner une telle désinfection. Avec la disponibilité généralisée des requêtes paramétrées dans les langages de programmation et les frameworks d’application, il n’y a aucune excuse pour utiliser des méthodes personnalisées. Ces méthodes peuvent être une solution de secours uniquement lorsque les requêtes paramétrées et les procédures stockées ne sont pas disponibles.

Des conseils spécifiques sur l’utilisation des requêtes paramétrées pour se protéger contre des types SQLi spécifiques sont contenus dans les sections dédiées aux types SQLi (injection SQL aveugle, injection SQL union, etc.).

Comment mitiger les attaques par injection SQL ?

Les méthodes possibles pour atténuer les attaques SQLi varient selon le type de logiciel vulnérable :

• Dans le cas de logiciels personnalisés, tels que les applications Web, le seul moyen d’atténuer de manière permanente le SQLi consiste à utiliser des requêtes paramétrées ou des procédures stockées si les requêtes paramétrées ne sont pas disponibles. Vous ne devez utiliser d’autres mesures que si le passage à des requêtes paramétrées nécessite un changement majeur dans la conception du logiciel, par exemple, si vous devez migrer une application PHP héritée de l’API MySQL d’origine vers PDO ou MySQLi.
• Dans le cas de SQLis connus dans un logiciel tiers, vérifiez les derniers avis de sécurité pour un correctif et mettez à jour vers une version non vulnérable (généralement la dernière version).
• Dans le cas de SQLis zero-day dans un logiciel tiers, vous ne pouvez compter que sur des règles WAF (pare-feu d’application Web) temporaires pour l’atténuation. Cependant, cela ne fait que rendre le SQLi plus difficile à exploiter et n’élimine pas la cause première du problème.
• Envisagez des mesures qui aideront à atténuer les dommages si une vulnérabilité SQLi existante est exploitée avec succès :
  • Développeurs : utilisez les privilèges les plus bas possibles pour l’accès à la base de données. Chaque fois que vous accédez à la base de données dans votre application, assurez-vous que vous utilisez un compte de base de données disposant des privilèges minimum nécessaires pour cette opération.
  • Administrateurs de base de données : désactivez toutes les options qui entraînent le renvoi de messages d’erreur de base de données à l’utilisateur, par exemple, dans les réponses HTTP. Activez temporairement ces options uniquement lors du débogage de votre code.
  • Administrateurs système : assurez-vous que les systèmes d’exploitation sous-jacents de l’application et du serveur de base de données sont sécurisés et à jour. Cela aidera à prévenir les attaques d’escalade de privilèges au cas où une vulnérabilité d’injection SQL existerait dans l’application.