Qu’est-ce que l’injection SQL exactement ?
Grâce à l’injection SQL, les pirates peuvent exécuter des commandes non autorisées sur la base de données SQL de la victime.
Qu’est-ce que l’injection SQL (SQi) ?
L’injection SQL (Structured Query Language) est une technique d’injection de code utilisée pour modifier ou supprimer des informations dans les bases de données SQL. En insérant des instructions SQL spécifiques dans un champ de saisie, un attaquant est en mesure d’exécuter des commandes pour récupérer des données dans des bases de données et détruire des données sensibles ou exécuter d’autres comportements de manipulation.
Lorsqu’il exécute correctement les commandes SQL, un utilisateur non autorisé peut se faire passer pour un utilisateur puissant, se faire passer pour un autre administrateur de base de données, modifier les données existantes, altérer les soldes et les transactions et supprimer toutes les informations du serveur.
Dans l’informatique moderne, l’injection SQL se produit généralement via Internet en envoyant des requêtes SQL malveillantes à un point de terminaison API proposé par un service ou un site web (nous y reviendrons). Dans le cas le plus grave, l’injection SQL peut permettre à un attaquant d’accéder à la racine d’un ordinateur et de prendre le contrôle total de la machine.
*SQL est un langage de programmation qui est utilisé pour gérer la majorité des bases de données.
Comment fonctionne une attaque par injection SQL ?
Imaginez une salle d’audience où un individu nommé Bob est en procès et doit comparaître devant un arbitre. Lorsqu’il remplit des formulaires avant le début du procès, Bob inscrit sur le papier « Bob est libre de partir ». Lorsque le juge se présente à son audience et lit à haute voix « Appelons maintenant Bob libre de partir », l’huissier laisse Bob partir car le juge le lui a dit.
Bien qu’il existe quelques types de SQLi légèrement différents, la vulnérabilité la plus importante est la même : le champ de requête SQL, qui était censé être réservé à un type de données spécifique, comme des chiffres, reçoit au contraire des informations involontaires, comme une commande. Une fois exécutée, cette commande est capable d’échapper aux limites de son objectif et peut déclencher un comportement potentiellement dangereux. Le champ de requête est généralement rempli avec des données saisies dans une page de formulaire en ligne.
Comparons rapidement les instructions SQL malveillantes et normales :
Requête SQL normale : Dans cette requête SQL normale, la chaîne studentID est passée dans une instruction SQL. L’objectif est d’effectuer une recherche dans la liste des étudiants pour trouver celui qui correspond à l’ID saisi par l’étudiant. Une fois l’étudiant trouvé, les informations le concernant sont retournées. En termes simples, la commande dit « allez localiser cette personne et donnez-moi ses coordonnées ».
Le code pourrait ressembler à ceci
studentId = getRequestString(« studentId ») ;
searchStudent = « SELECT * from students WHICH studentID is » + studentId
Si un étudiant remplit un numéro d’identification à partir du 117 dans un formulaire se trouvant sur la page du site Web qui indique « Please fill in your student ID number.
champ de formulaire normal
la requête SQL résultante semblerait être :
SEARCH * STUDENTS WHERE STUDENTID = 117 ;
Cette commande renverra les informations concernant l’étudiant spécifique qui possède un studentId, ce qui est exactement ce que la personne qui a créé l’API espère voir se produire.
Requête d’injection SQL :
Dans ce scénario, un attaquant saisit une commande SQL ou une logique conditionnelle dans le champ de saisie. Et saisit ensuite l’ID d’un étudiant :
Champ de formulaire de l’exemple d’injection SQL
Bien que la procédure normale consiste à rechercher l’ID approprié dans la table de la base de données recherche maintenant un ID, ou teste pour déterminer si 1 est égal à 1. Comme vous pouvez l’imaginer, cela reste valable pour chaque étudiant présent dans la colonne et la base de données renvoie toutes les données de la table des étudiants à la personne qui utilise la requête.
SQLi cible l’API ou interface de programmation d’application vulnérable. Dans ce cas, l’API désigne l’interface logicielle par laquelle les serveurs reçoivent et répondent aux demandes.
Il existe des outils qui permettent à un criminel de rechercher des formulaires sur un site Web, puis d’essayer de saisir plusieurs requêtes SQL susceptibles de générer une erreur que les développeurs du logiciel du site Web n’avaient pas l’intention d’utiliser pour accéder à la base de données.
Les injections SQL sont relativement faciles à mettre en place et, plus important encore, elles sont assez faciles à arrêter si vous suivez les bonnes pratiques en matière de développement. Cependant, la réalité est un peu plus floue car les délais sont courts, les développeurs inexpérimentés et le code ancien peuvent conduire à une sécurité et une qualité de code incohérentes. Un seul champ faible sur le formulaire ou le point de terminaison API d’un site ayant accès à une base de données peut suffire à révéler une vulnérabilité.
Comment prévenir l’éventualité d’une attaque par injection SQL ?
Il existe de nombreuses façons de minimiser le risque de violation de données causée par une injection SQL. La meilleure pratique consiste à utiliser plusieurs stratégies. Examinons quelques-unes des mises en œuvre les plus populaires :
Utilisation d’instructions préparées (avec des requêtes paramétrées), cette approche de l’assainissement des entrées de la base de données exige que les développeurs définissent d’abord l’ensemble des codes SQL avant d’utiliser des paramètres spécifiques pour la requête SQL. Les informations saisies sont soumises à une limite spécifique qu’elles ne peuvent pas dépasser. Cela permet à la base de données de faire la distinction entre les données saisies et le programme à exécuter, quel que soit le type d’informations saisies dans le champ de saisie. Certaines bibliothèques de mappage objet-relationnel (ORM) sont généralement utilisées pour cela, car certaines versions nettoient automatiquement les entrées dans les bases de données.
Se débarrasser de toutes les entrées fournies par l’utilisateur Lors de l’écriture de SQL, des caractères ou des mots particuliers se voient attribuer une signification distincte. Par exemple, le caractère « * » fait référence à « tout » tandis que le terme « OR » est une condition. Pour éviter que des utilisateurs n’aient saisi ces caractères dans une requête API, les entrées fournies par l’utilisateur peuvent être masquées. En échappant un caractère, vous indiquez efficacement à la base de données de ne pas interpréter l’entrée comme une commande ou une condition, mais de la traiter comme une entrée réelle.
Utilisation de procédures stockées Bien qu’elles ne constituent pas une stratégie de sécurité en soi, les procédures stockées peuvent limiter les risques associés à l’injection SQL. En limitant les autorisations accordées au compte qui exécute les requêtes SQL, même les logiciels faibles qui sont sensibles à l’injection SQL ne recevront pas les autorisations nécessaires pour modifier des tables qui ne sont pas liées à la base de données. Les procédures stockées examinent également le type de paramètres d’entrée et empêchent l’entrée de données qui ne sont pas conformes à la nature de l’entrée pour laquelle le champ a été créé. Lorsque les requêtes statiques ne sont pas suffisantes, les procédures stockées ne sont généralement pas recommandées.
Utilisez le concept du moindre privilège. En général, lorsque le site Web doit utiliser du SQL dynamique, il est essentiel de minimiser le risque d’injection SQL en limitant les autorisations au plus petit champ nécessaire pour exécuter la requête demandée. Dans son sens le plus simple, cela implique qu’un compte administrateur ne doit pas exécuter de commandes SQL après une demande d’API provenant d’une personne non autorisée. Alors que les procédures stockées ne doivent être utilisées que pour des requêtes statiques. L’utilisation du principe du moindre privilège peut aider à réduire le risque des requêtes SQL dynamiques.
Quelle est la définition exacte d’une attaque par injection SQL composée ?
Pour contourner les mesures de sécurité, les attaquants avisés peuvent utiliser des attaques multi-vecteurs sur des sites Web ciblés. Bien qu’une seule attaque puisse être évitée, elle peut attirer l’attention des administrateurs de bases de données et des équipes de sécurité travaillant sur les informations. Les attaques DDoS, le détournement de DNS et d’autres techniques de perturbation sont souvent utilisés pour détourner la mise en œuvre des attaques par injection SQL. Ainsi, une stratégie globale d’atténuation des menaces offre la sécurité la plus complète. Le Web Application Firewall de Cloudflare, l’atténuation des attaques DDoS ainsi que la sécurité DNS sont des éléments vitaux d’un plan de sécurité complet.
