_edited.png)
Avant d'entrer dans le sujet "Injection SQL", définissons d'abord le langage SQL (ou Structured Query Language). C'est le langage utilisé pour communiquer avec les bases de données relationnelles ; c'est le langage de requête utilisé par les développeurs, les administrateurs de bases de données et les applications pour gérer tout type de données générées chaque jour. À ne pas confondre avec un système de gestion de bases de données relationnelles (SGBD ou SGBDR) tel que Postgresql, MariaDB ou MSSQL.
Quel intérêt pour les attaquants?
L'injection SQL est l’une des vulnérabilités les plus anciennes encore présente dans l'OWASP TOP 10 depuis plus de quinze ans. Elle permet de voler et modifier les informations (sensibles ou non), accessibles dans des millions de bases de données dans le monde entier.
Les données semblent être devenues l'une des marchandises les plus convoitées du monde... et quand quelque chose a de la valeur, cela attire l’attention de personnes peu recommandables qui voudront mettre la main dessus à n'importe quelle prix.
Ainsi les développeurs doivent comprendre l'injection SQL si nous voulons nous en protéger.
Comprendre l'injection SQL
Au sein d'une application, deux contextes existent :
l'un pour les données,
l'autre pour le code.
Le contexte de code indique à l'ordinateur ce qu'il doit exécuter et ce qu’il doit séparer des données à traiter.
L'injection SQL se produit lorsqu'un attaquant entre des données qui sont traitées par erreur comme du code par l'interpréteur SQL.
Prenons par exemple : le champ de saisie d’un formulaire (combo identifiant/mot de passe) sur un site web, dans lequel un attaquant entre "' OR 1=1;”. Cette chaine de caractère spécifique est ajoutée à la fin d'une requête SQL. Lorsque cette requête est exécutée, elle permet l'attaquant de bypasser l'authentification sans connaissance du mot de passe.
Les implications de l'injection SQL peuvent être catastrophiques. Si cela se produit sur une page de connexion, elle peut renvoyer tous les enregistrements d'utilisateurs, y compris les noms d'utilisateurs et les mots de passe. Si une simple requête pour extraire des données est réussie, les requêtes pour modifier des données le seront également.
Pourquoi l'injection SQL est si dangereuse
Un constat peut être dressé à la lecture d’un rapport Web Application Attack Report (WAAR) d’Imperva publié en Février 2020 : 29% des applications Web, sont encore aujourd’hui vulnérables aux injections SQL.
Voici trois exemples de violations causées par l'injection SQL :
La sécurité des plugins d’un des systèmes de gestion de contenu (CMS : Content Management System) les plus populaire, Wordpress, serait vulnérable à beaucoup d’exploits web. Les chercheurs espagnols en sécurité Jacinto Sergio Castillo Solana et Manuel Garcia Cardenas ont découvert plus de 5 000 vulnérabilités, dont 4 500 failles d'injection SQL (SQLi) sur plus de 84000 plugins. Les vulnérabilités impliquant des plugins WordPress sont devenues une source bien documentée de problèmes secondaires affectant les sites web. (Source)
Hetzner, une société sud-africaine d'hébergement de sites web, a été victime d'une violation de 40 000 enregistrements de clients. Une vulnérabilité par injection SQL a conduit au vol possible de chaque enregistrement client dans leur base de données. (Source)
Un nouveau type d’injection SQL a fait son apparition en 2019, “Voice-Command SQL Injection”. Comme son nom l’indique, cette attaque est basée sur les commandes vocales pour effectuer l’injection. Afin d'illustrer cette vulnérabilité et de créer une plus grande prise de conscience, le responsable de la sécurité et du piratage éthique de Protego, Tal Melamed, illustre comment une simple injection SQL peut être exécutée par une commande verbale afin d'obtenir un accès non autorisé aux données sensibles d'un compte. Cette démonstration montre comment, dans ce cas, Alexa, peut être exploité dans une application non protégée, en traduisant des mots et des chiffres. (Source)
Les données sensibles peuvent être utilisées pour reprendre des comptes, réinitialiser des mots de passe, voler de l’argent, usurper votre identité ou encore commettre des fraudes.
Les informations qui ne sont pas considérées comme sensibles ou personnelles identifiables peuvent également être utilisées pour d'autres attaques. Les adresses, couplées à d’autres informations peuvent par exemple être utilisées pour usurper votre identité auprès d'entreprises ou réinitialiser votre mot de passe.
Lorsqu'une attaque est réussie, les clients peuvent perdre confiance dans l'entreprise. Le recouvrement des dommages causés aux systèmes ou les amendes réglementaires payées peuvent coûter des millions d’euros.
Mais cela ne doit pas forcément se passer ainsi.
Vaincre l'injection SQL
L'injection SQL peut être défaite en étiquetant clairement les parties de votre application, de sorte que l'ordinateur sache si une certaine partie est une donnée ou un code à exécuter. Cela peut se faire à l'aide de requêtes paramétrées.
Lorsque les requêtes SQL utilisent des paramètres, l'interpréteur SQL utilisera le paramètre uniquement comme données. Il ne l'exécute pas en tant que code.
Par exemple, une attaque telle que "' OR 1=1;" ne fonctionnera pas. La base de données cherchera la chaîne "OR 1=1;" en son sein et ne la trouvera pas. Elle haussera simplement les épaules et dira : "Désolé, je ne peux pas trouver ça pour vous."
La plupart des cadres de développement fournissent des défenses intégrées contre l'injection SQL.
Les Object Relational Mappers (ORM), tels que l'Entity Framework dans la famille .NET, paramètreront les requêtes par défaut. Cela permettra de prendre en charge l'injection SQL sans aucun effort de votre part.
Cependant, vous devrez savoir comment fonctionne votre ORM spécifique. Par exemple, Hibernate, un ORM populaire dans le monde Java, peut toujours être vulnérable à l'injection SQL s'il est mal utilisé.
Le paramétrage des requêtes est la première et la meilleure défense à adopter, mais d’autres existent. Les procédures stockées prennent également en charge les paramètres SQL et peuvent être utilisées pour empêcher l'injection SQL. Gardez à l'esprit que les procédures stockées doivent également être construites correctement pour que cela fonctionne.
Validez et aseptisez toujours vos entrées. Étant donné que certains caractères, tels que “OR 1=1;", ne seront pas saisis par un utilisateur légitime de votre application, il n'est pas nécessaire de les autoriser. Vous pouvez afficher un message d'erreur à l'utilisateur ou le supprimer de votre saisie avant de la traiter.
Néanmoins, ne comptez pas uniquement sur la validation et l'aseptisation pour vous protéger. Des personnes malveillantes ont trouvé des moyens de contourner cette solution. Ce sont de bonnes stratégies de Défense en profondeur (DDP), mais le paramétrage est le moyen le plus sûr de couvrir toutes les bases. L’idéal étant d’associer les défenses.
Une autre bonne stratégie de défense en profondeur consiste à utiliser les "moindres privilèges" dans la base de données et les entrées de la liste blanche. L'application du moindre privilège signifie que votre application n'a pas un pouvoir illimité dans la base de données. Si un attaquant devait y accéder, les dommages qu'il pourrait causer seraient donc limités.
L'OWASP dispose d'une excellente "Cheat Sheet" sur l'injection SQL qui montre comment gérer cette vulnérabilité dans plusieurs langage et sur plusieurs plateformes.
Enfin, une autre solution consiste à faire appel à nos services afin de profiter de notre expertise et de nos conseils pour vous aider à une sécurisation optimale et personnalisée de vos applications web !
Articles complémentaires :
Vous avez apprécié cet article de blog ?
Retrouvez plus de contenus en rapport avec la cybersécurité et la conformité réglementaire au RGPD sur le blog de CyberSecura !
Nous avons besoin de vos réponses !
En répondant à cette enquête, vous nous permettez de mieux comprendre vos interactions avec notre site ainsi que vos potentiel besoins.
Vos réponses sont anonymes, et à moins que vous ne demandiez à être re-contacté(e) par nos équipes, aucune information personnelle ne vous est demandée !
Merci pour vos réponses !
Vous souhaitez être informé(e) de nos actualités, et recevoir nos derniers articles de blog directement dans votre boite mail ? Abonnez-vous à notre newsletter mensuelle !
Vous souhaitez discuter de vos difficultés, de vos besoins, de nos offres ? Demandez à être contacté, gratuitement et sans engagement, par l'un de nos expert en cybersécurité !
Comments