Nombreux sont les sites web qui fonctionnent avec une base de données en arrière-plan. Souvent, un outil CMS (Content Management System) est disponible pour gérer les données à partir de formulaires, sans que l'utilisateur ait besoin de posséder des connaissances en programmation ou en HTML.
Or, pour se connecter à l'outil CMS, on doit entrer un nom d'utilisateur et un mot de passe, qui eux, sont généralement stockés dans une table de la base de données. L'interface d'identification permet donc de fournir les paramètres nécessaires pour compléter la requête SQL qui procédera à l'authentification.
Par exemple, si les paramètres fournis sont les suivants :
username = 'code18'
password = 'cornichon'
La requête exécutée devrait ressembler à quelque chose comme ce qui suit puisque très souvent, elle est construite en concaténant les valeurs reçues directement dans la requête SQL :
SELECT * FROM users
WHERE username = 'code18' AND password = 'cornichon'
Et le problème est là. S'il n'y a pas de validation des paramètres, il y a un risque qu'on puisse entrer du code qui vient altérer la nature de la requête. Par exemple, si on passe une valeur contenant une apostrophe dans un des champs, la syntaxe de la requête SQL devient invalide (WHERE username = 'code' 18' AND ...) et le serveur lance un message d'erreur. Si le serveur ne cache pas ces messages ou qu'une page d'erreur 500 n'est pas activée, vous êtes encore plus vulnérable car les messages d'erreurs que lancera le serveur de base de données (SQL Server) sont assez explicites.
Une bonne façon de faire planter une requête SQL est d'entrer n'importe quoi comme nom d'utilisateur ainsi que la chaîne de caractères ' HAVING 1=1;-- au lieu du mot de passe.
Le résultat que le serveur tentera d'exécuter :
WHERE username = 'blablabla' AND password = '' HAVING 1=1;--'
Ici, l'apostrophe permet de fermer la chaîne pour avoir une syntaxe valide (donc une comparaison avec un mot de passe vide). La clause HAVING sera celle qui permettra de générer une erreur dans la requête, car ne peut être utilisée qu'en combinaison avec la clause GROUP BY (1=1 représente une condition qui retourne toujours vrai, pour le besoin de la cause). On termine le tout en fermant l'énoncé SQL par le symbole ";" et on commente le reste de la requête s'il y a lieu avec "--". Une fois exécutée, un message d'erreur devrait apparaître :
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.realname' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.
Voilà, la base de données vient de nous faire cadeau non seulement du nom de la table, mais aussi du nom d'un champ!
Comme on en sait un peu plus, on peut reprendre le processus en tentant d'injecter autre chose. Dans le champ mot de passe, si on entre '; SELECT * FROM users GROUP BY realname;--, on fait en sorte qu'on exécute une seconde requête à la suite de l'originale qui demande à la base de données de nous retourner tous les champs de la table users, ce qui provoque une autre erreur causée par le GROUP BY qui ne peut fonctionner en raison du SELECT *.
[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.username' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.
En répétant le processus, on arrive à obtenir le nom de tous les champs. Vous voyez l'idée ? Rien de plus simple ensuite pour insérer du contenu, effectuer une mise à jour pour changer de mot de passe sur un compte et même obtenir un nom d'usager et son mot de passe (il y a une astuce ici mais je ne vous dis pas tout, mon objectif étant de vous sensibiliser au concept pour améliorer votre programmation et non d'en tirer profit ou en vous incitant à des pratiques douteuses).
En conclusion :
- validez toujours les paramètres reçus (GET ou POST)
- cacher ou désactivez les erreurs et alertes du serveur
- créez une page d'erreur 500
- encryptez les mots de passe avec un salt
- utilisez des procédures stockées
