Dans le cadre de notre projet de fin de Licence 3 en Informatique, mon groupe et moi nous intéressons à l'identification, l'exploitation et la correction des failles de sécurité web.Pour ma part, j'ai décidé de me concentrer d'abord sur les injections SQL. Cette semaine, j'ai suivi un cours sur HTB Academy pour approfondir mes connaissances sur les SQLi.
Étant donné les conséquences dramatiques que peut entraîner cette vulnérabilité, je vous partage ici ce que j'ai compris et appris à ce sujet.
Un exemple concret :
Lorsque vous vous connectez à un service web, vous entrez votre identifiant et votre mot de passe. Le formulaire se charge d'envoyer les données saisies au serveur. La vérification et la connexion à votre compte sont réalisées côté serveur. Souvent en interrogeant une base de données pour vérifier l'existence d'un utilisateur correspondant. Le langage le plus utilisé pour interagir et interroger une base de données est le SQL. SQL pour Structured Query Language.
Il y a toutefois un problème. En effet, si la vérification côté serveur n'est pas bien codée : cela mène à une faille de sécurité notable : l'injection SQL.
Qu'est-ce que l'injection SQL ?
Il s'agit d'exploiter une mauvaise implémentation des interactions avec la base de données, afin de provoquer un comportement inattendu. Entendez par "comportement inattendu" : connexion en tant qu'un autre utilisateur, affichage du contenu de la base de données, etc.
Cette vulnérabilité survient lorsque le code côté serveur ne valide pas correctement les données saisies par l'utilisateur. Ce qui n'est évidemment pas prévu au départ. Cela se produit lorsque l'utilisateur est techniquement capable d'écrire dans le code back-end.
Quelles conséquences ?
Pour exploiter cette vulnérabilité, l'acteur malveillant va essayer d'ajouter une autre requête à celle d'origine.
Dans le premier exemple, je vous parlais de la connexion à un service en ligne. Dans ce cas, l'attaquant pourrait exploiter une faille d'injection SQL pour désactiver la vérification du mot de passe (en commentant la condition, elle ne serait pas exécutée).
Donc si l'identifiant est correct, qu'il existe dans la base de données. Alors, l'utilisateur serait connecté au compte correspondant à cet identifiant. Le serveur ne vérifiant plus la correspondance du mot de passe.
Si l'attaquant arrive à ajouter sa propre requête, il pourrait même afficher le contenu de la base de données. Ces données pourraient concerner les autres utilisateurs du service ou bien la société elle-même.
Enfin, si l'utilisateur SQL dispose du privilège FILE : c'est à dire qu'il a le droit de lire et d'écrire des fichiers. Alors, l'acteur malveillant pourrait créer un web shell (invite de commande) sur le serveur distant. L'exécution d'un tel shell mènerait à une RCE (Remote Code Execution) = Execution de commande système à distance.
Dans le TOP 10 de l'OWASP en 2021 ...
Les injections SQL sont une faille de sécurité référencée en 3ème position dans le TOP 10 2021 par l'OWASP.
L'OWASP (Open Web Application Security Project) est une organisation mondiale à but non-lucratif dédiée à l'amélioration de la sécurité des applications web.
Comment s'en protéger ?
L'idée est d'utiliser des requêtes préparées, où la requête SQL écrite en amont n'attend plus que des paramètres. Ainsi, les données de l'utilisateur seront forcément considérées comme les paramètres et jamais comme du code SQL.
Cela permet d'améliorer grandement la sécurité, en limitant drastiquement les risques contre les injections SQL. Les requêtes préparées gagnent aussi en performance. PHP est un langage côté serveur largement utilisé pour les sites dynamiques. Les requêtes préparées existent en PHP, mais aussi dans d'autres langages back-end.
Vérifier que vous n'êtes pas exposés aux injections SQL est donc essentiel.