Comme plusieurs langages de programmation, le langage SQL (structured query language) est vulnérable aux manipulations et aux abus par les hackers. SQL est couramment utilisé pour interroger, activer et administrer des bases de données par le biais d’une application. Des applications peuvent parfois être activées depuis un navigateur, notamment via une page web, un commentaire, un forum ou une API. Lorsqu’une injection SQL est présente dans une application, les requêtes SQL émises par le navigateur peuvent être modifiées par des hackers pour réaliser des actions dépassant le périmètre de l’application, et générer ainsi une faille de sécurité ou une perte de données. Il existe bien sûr des techniques que les développeurs de l’application peuvent utiliser pour se protéger contre cette menace spécifique.
Cet article se focalisera sur ce qu’est une attaque par injection SQL, son fonctionnement et comment les développeurs et les administrateurs peuvent se protéger contre cette menace sérieuse.
Une attaque par injection SQL est utilisée par les acteurs malveillants pour empoisonner les requêtes de SQL dans l’intention de compromettre la base de données de backend d’une application web. Il est important de souligner que cette vulnérabilité réside dans l’application et non dans la base de données. Cela signifie qu’il appartient aux développeurs de prendre des mesures pour se protéger contre cette menace lorsqu’ils élaborent cette application afin que les vulnérabilités soient identifiées avant de créer des dommages.
En 3e position du Top 10 OWASP 2021, une attaque par injection SQL réussie commence lorsqu’un hacker entre un code malveillant dans le corps d’une requête par le biais d’une application web. En raison de pratiques de codage non sécurisées, le côté du serveur d’une application est ensuite piégé pour faire passer la requête injectée dans la base de données, même si au niveau de sa conception, ce n’est pas son but. Une fois que la requête malveillante trouve son chemin vers la base de données, elle sera exécutée ainsi. Étant donné que le rôle de la base de données est d’exécuter des requêtes, elle suivra les ordres aveuglément. Cela peut créer d’importants dommages qu’il peut être difficile de réparer. La demande injectée peut avoir des fonctionnalités allant au-delà de ce pour quoi l’application a été conçue. Des données peuvent fuiter ou être supprimées ou bien des indices précieux sur la façon dont la base de données backend est construite et quel type de données s’y cache.
Comme mentionné ci-dessus, une injection SQL se produit dans l’application même dans le but d’accéder à des données figurant dans la base de données backend qui, autrement, ne seraient pas disponibles. Le hacker peut utiliser la vulnérabilité de l’application, sans défaut dans la base de données, pour réaliser son attaque.
Une faille SQL peut être utilisée pour :
Contourner les protocoles d’authentification ou d’autorisation du site web pour permettre à l’attaquant de consulter des dossiers sensibles dans la base de données (cartes bancaires, informations personnelles, etc.)
Récupérer, ajouter, modifier ou supprimer du contenu de la base de données backend
Obtenir le contrôle de tout le serveur en accédant au système d’exploitation
Réaliser des opérations administratives
Toutes les attaques par injection SQL utilisent les données fournies à l’attaquant pour modifier les déclarations SQL de l’application web, mais il existe différentes manières de mettre cela en place. Sauf si l’application ciblée utilise une validation stricte des données entrantes, elle reste vulnérable à toutes ces attaques.
Il s’agit d’une injection SQL très basique où un attaquant remarque les différences dans les messages d’erreur qui leurs sont renvoyés. Lorsqu’un hacker examine les messages d’erreur, il peut déchiffrer plusieurs choses sur la base de données, y compris le type de données stockées à l’intérieur et comment les tableaux et les colonnes sont construits.
Cette attaque a lieu lorsque le hacker trouve un défaut d’injection SQL dans une application et que les résultats de la requête sont renvoyés dans les réponses de l’application. Le mot-clé UNION peut être utilisé pour récupérer des données depuis d’autres tableaux de la base de données.
Une injection SQL à l’aveugle surgit lorsqu’une application est vulnérable à une injection SQL mais que ses réponses HTTP ne contiennent pas les résultats de la bonne requête SQL ou les détails des erreurs de la base de données. Il existe deux versions d’attaques à l’aveugle :
Booléenne - L’attaquant pose une série de questions oui-ou-non pour réunir des informations sur la base de données.
Basée sur le temps - L’attaquant demande à la base de données de prendre un peu plus de temps pour répondre. Cela l’oblige à modifier le temps qu’il lui faut pour exécuter une requête, ce qui peut perturber la base de données et l’inciter à révéler des données sensibles.
Le développeur doit programmer et suivre avec attention la façon dont l’application interagit avec la base de données. Un développeur devrait penser au cycle de vie d’une application et créer dès le départ des remparts de sécurité.
Il s’agit de requêtes pré-établies dans lesquelles le développeur place les données de l’utilisateur dans la requête lors de son exécution. Étant donné qu’elle avertit en amont la base de données de ce que la requête est censée faire, il est impossible pour le hacker de manipuler cette fonction.
Lancez-vous dès Aujourd'hui
Découvrez comment Ping peut vous aider à protéger vos employés et améliorer l'expérience de vos clients dans un monde digital en constante évolution.
Démonstration Gratuite
Nous vous remercions ! Veuillez consulter votre boîte email.