Comment se déroule une attaque par injection SQL
qui effectuent des requêtes SQL à partir d'entrées utilisateur sont potentiellement vulnérables aux attaques par injection SQL. Par exemple, une application Web peut utiliser des requêtes SQL pour mettre en œuvre un processus d'authentification. L'utilisateur fournit son nom d'utilisateur, que l'application utilise pour rechercher le hachage du mot de passe du compte de cet utilisateur. Si le hachage du mot de passe fourni par l'utilisateur correspond à ce hachage, l'utilisateur s'authentifie avec succès et accède à son compte.
Si l'application Web n'effectue pas de validation sur le nom d'utilisateur avant de l'inclure dans une requête SQL, un nom d'utilisateur délibérément mal formé pourrait être mal interprété par le programme. Par exemple, les requêtes SQL utilisent généralement des guillemets simples (') ou doubles (") pour désigner les données d'une commande. Par exemple, une commande permettant de rechercher l'enregistrement d'un client dans une base de données sur la base du nom d'utilisateur user pourrait être la suivante SELECT * FROM customers WHERE username="user" (nom d'utilisateur = "utilisateur").
Un attaquant effectuant une attaque par injection SQL contre sa commande pourrait inclure un caractère de guillemet double dans son entrée pour que certaines de ses données soient interprétées comme du code. Prenons l'exemple du nom d'utilisateur utilisateur" OU "1"="1.
Lorsqu'elle est insérée dans la requête SQL, la requête devient SELECT * FROM customers WHERE username="user" OR "1"="1". Au lieu de rechercher les enregistrements dont le nom d'utilisateur correspond à la valeur fournie par l'utilisateur, cette requête renvoie les enregistrements qui répondent à l'une des deux conditions suivantes. Le premier est le test prévu username="utilisateur"qui renverra le dossier de l'utilisateur.
La deuxième condition est le test "1"="1". Comme cela est toujours vrai, tous les enregistrements de la base de données seront renvoyés. Cela pourrait permettre à l'attaquant d'extraire des informations sensibles sur d'autres utilisateurs ou de contourner l'authentification ou de s'authentifier en tant qu'autre utilisateur.
Types d'injection SQL
Les attaques SQLi peuvent être utilisées à différentes fins et de différentes manières. Les trois principaux types de SQLi sont les suivants :
- SQLi en bande : Les attaques SQLi en bande utilisent le même support, tel qu'une requête HTTP, pour effectuer leurs attaques et collecter les résultats. Les attaques SQLi basées sur les erreurs, qui tentent de générer des messages d'erreur fournissant des informations sur la base de données cible à utiliser dans les attaques, et les attaques SQL basées sur l'union, qui utilisent l'opérateur SQL UNION pour fusionner les instructions SQL SELECT, sont deux formes courantes d'attaques SQLi liées.
- SQLi aveugle : Dans une attaque SQLi aveugle, l'attaquant ne reçoit pas de données du serveur en fonction de ses demandes. Au lieu de cela, l'attaquant modifie ses attaques en fonction du comportement du serveur. Par exemple, différentes entrées peuvent entraîner la réussite ou l'échec d'une opération ou avoir un impact sur le temps nécessaire à l'exécution d'une opération.
- SQLi hors bande : Les attaques SQLi hors bande effectuent une attaque sur un support et collectent des données sur un autre. Cette attaque repose sur la disponibilité de certaines fonctionnalités sur le serveur de base de données. Par exemple, un attaquant peut mesurer le succès d'une attaque SQLi en fonction de sa capacité à forcer le serveur de base de données à générer des requêtes HTTP ou DNS vers un serveur contrôlé par l'attaquant.
Comment prévenir le SQLI
Les attaques SQLi tirent parti d'une mauvaise validation des entrées lors de l'utilisation de données non fiables pour les commandes SQL. De nombreuses attaques SQLi impliquent l'utilisation d'un caractère inattendu, tel qu'un guillemet simple ou double, dans la saisie de l'utilisateur.
La validation des entrées avant d'inclure des données fournies par l'utilisateur dans des requêtes SQL peut contribuer à réduire la menace des attaques SQLi. Par exemple, une application peut limiter la saisie de l'utilisateur à un ensemble particulier de caractères, en n'autorisant par exemple que les noms d'utilisateur alphanumériques, ou empêcher certains caractères d'être inclus dans la saisie de l'utilisateur. Cependant, la validation des entrées, bien qu'importante, n'est pas suffisante pour se protéger contre les attaques par injection de code SQL. Les attaquants peuvent être en mesure de contourner les listes d'autorisation ou les listes de blocage en utilisant des combinaisons inattendues de caractères pour éviter les blocages.
C'est pourquoi les entreprises devraient également déployer un Pare-feu pour applications Web (WAF) ou, idéalement, Protection des applications Web et des API (WAAP) devant l'application Web et les API qui effectuent des requêtes SQL. Ces solutions peuvent aider à identifier et à bloquer les requêtes malveillantes qui tentent d'exploiter SQLi et d'autres attaques contre les applications Web et les API.
Prévention SQLi avec Point de contrôle
Les attaques SQLi sont l'une des nombreuses attaques qui menacent les systèmes d'information d'une organisation. application sécurité (AppSec). Les entreprises ont besoin de solutions de sécurité capables de protéger leurs applications et bases de données orientées vers l'Internet, à la fois sur site et sur le site cloud.
Check Point CloudGuard AppSec fournit des capacités WAAP automatisées qui apprennent comment fonctionne un site application et empêchent les demandes illégitimes et malveillantes d'atteindre les applications vulnérables. Pour en savoir plus sur CloudGuard AppSec et sa capacité à protéger contre SQLi et d'autres attaques, consultez ce document eBook. Vous êtes également invités à inscrivez-vous pour un démo gratuit pour découvrir par vous-même les capacités de CloudGuard AppSec.
Commentaires