Phenquestions
La vulnérabilité de troncature SQL existe généralement dans les bases de données MySQL. Cette vulnérabilité a été décrite pour la première fois dans CVE-2008-4106, qui était liée au CMS WordPress.
Comment fonctionnent les attaques par troncature SQL
Cette attaque fonctionne grâce à la troncature des entrées utilisateur dans les bases de données à l'aide des fonctions 'sélection' et 'insertion'.
- Lorsque l'entrée est donnée dans le champ du formulaire, la fonction 'select' vérifie la redondance correspondant aux entrées dans la base de données.
- Après avoir vérifié la redondance, la fonction « insertion » vérifie la longueur de l'entrée, et l'entrée utilisateur sera tronquée si la longueur dépasse.
Supposons qu'un développeur crée la table « users » via la requête suivante :
créer des utilisateurs de table(user_id INT NON NULL AUTO_INCREMENT,
nom_utilisateur VARCHAR(20) NON NULL,
mot de passe VARCHAR(40) NON NULL,
CLÉ PRIMAIRE ( user_id )
);
En utilisant ce schéma, si le développeur crée un compte administrateur avec les éléments suivants :
nom_utilisateur = 'admin'mot de passe = "secret_p4ssword"
De toute évidence, ces informations d'identification ne sont pas publiques. Il n'y a qu'un seul compte administrateur dans la base de données, et si un attaquant essaie d'enregistrer un autre compte avec le nom d'utilisateur 'admin', l'attaquant échouera en raison des contrôles de redondance de la base de données. L'attaquant peut toujours contourner ce contrôle de redondance pour ajouter un autre compte administrateur en exploitant la vulnérabilité de troncature SQL. Supposons que l'attaquant enregistre un autre compte avec l'entrée suivante :
User_name = 'adminxxxxxxxxxxxxxxxrandom'(x sont les espaces)
&
Mot de passe = "Utilisateur aléatoire"
La base de données prendra le 'user_name' (26 caractères) et vérifiera s'il existe déjà. Ensuite, l'entrée user_name sera tronquée et 'admin '('admin' with space) sera entré dans la base de données, ce qui entraînera deux utilisateurs admin en double.
L'attaquant est alors capable de créer un utilisateur 'admin' avec son propre mot de passe. Maintenant, la base de données a deux entrées admin 'user_name', mais avec des mots de passe différents. L'attaquant peut se connecter avec les informations d'identification nouvellement créées pour obtenir un panneau d'administration car les deux noms d'utilisateur « admin » et « admin » sont égaux pour le niveau de la base de données. Maintenant, nous allons examiner un exemple d'attaque pratique.
Exemple d'attaque
Dans cet exemple, nous prendrons un scénario du site Web overthewire.organisation. La communauté overthewire fournit des CTF de wargame sur lesquels nous pouvons mettre en pratique nos concepts de sécurité. Le scénario de troncature SQL se produit dans le jeu natas Niveau 26->27. Nous pouvons accéder au niveau en utilisant les éléments suivants :
URL : http://natas27.natas.laboratoires.sur le fil.organisationNom d'utilisateur : natas27
Mot de passe : 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Ce niveau est disponible sur : https://overthewire.org/wargames/natas/natas27.html. Une page de connexion vulnérable à une attaque par troncature SQL s'affichera.
En inspectant le code source, vous verrez que la longueur du nom d'utilisateur est de 64, comme indiqué ci-dessous.
Un utilisateur nommé 'natas28' existe déjà. Notre objectif est de créer un autre utilisateur nommé 'natas28' en utilisant l'attaque SQL_truncation. Nous allons donc saisir natas28, suivi de 57 espaces et d'un alphabet aléatoire (dans notre cas, a), d'un nom d'utilisateur et de tout mot de passe. La lettre « a » n'est pas visible dans la capture d'écran en raison du nom d'utilisateur de 65 caractères. Après la création du compte utilisateur, vous pourrez voir le 'une.'
Si la base de données contient la vulnérabilité sql_truncation, alors la base de données devrait maintenant avoir deux noms d'utilisateur 'natas28'. Un nom d'utilisateur contiendra notre mot de passe. Essayons de saisir les informations d'identification sur la page de connexion.
Maintenant, nous sommes connectés en tant qu'utilisateur 'natas28'.
Atténuation
Pour atténuer cette attaque, nous devrons considérer plusieurs facteurs.
- Nous ne devrions pas autoriser la duplication d'identités critiques comme le nom d'utilisateur. Nous devrions faire de ces identités des clés primaires.
- La fonction truncate doit être implémentée pour tous les champs des formulaires frontend, ainsi que le code backend, afin que les bases de données reçoivent des entrées tronquées.
- Le mode strict doit être activé au niveau de la base de données. Sans le mode strict activé, les bases de données ne donnent que des avertissements dans le backend, mais enregistrent toujours les données dupliquées. En mode strict, les bases de données donnent des erreurs en cas de duplication et évitent de sauvegarder les données.
Par exemple, vérifions le mode strict à l'aide de la requête suivante :
mysql> sélectionnez @@sql_mode
Nous allons créer une base de données et la table 'users.'
test mysql> CRÉER UNE BASE DE DONNÉESRequête OK, 1 ligne affectée (0.02 s)
mysql> Utiliser le test
Base de données modifiée
mysql> utilisateurs CREATE TABLE (nom d'utilisateur VARCHAR (10), mot de passe VARCHAR (10));
Requête OK, 0 lignes affectées (0.05 s)
Ensuite, nous allons créer un utilisateur administrateur avec des informations d'identification à l'aide de la requête INSERT.
mysql> INSÉRER DANS LES VALEURS des utilisateurs ('admin', 'password1');Requête OK, 1 ligne affectée (0.01 s)
Nous pouvons voir les informations du tableau 'users' en utilisant l'option 'select * from users'.
La longueur du nom d'utilisateur est de 10 caractères. Maintenant, nous allons essayer l'attaque par troncature SQL.
Lorsque nous essayons de saisir les éléments suivants :
Nom d'utilisateur = 'adminxxxxxa'(x sont les espaces)
&
Mot de passe = 'pass2'
Nous obtiendrons une erreur, ce qui signifie que le mode strict est totalement efficace.
mysql> INSÉRER DANS les valeurs des utilisateurs('admin a', 'pass2')ERREUR 1406 (22001) : données trop longues pour la colonne « nom d'utilisateur » à la ligne 1
Sans le mode strict activé, la base de données affichera des avertissements, mais insérera toujours les données dans la table.
Conclusion
Les attaquants peuvent accéder à des comptes à privilèges élevés si la vulnérabilité sql_trunction existe dans votre application. L'attaquant peut facilement obtenir des informations sur un nom d'utilisateur et sa longueur de base de données en utilisant les champs critiques, puis créer le même nom d'utilisateur, suivi d'espaces et d'un alphabet aléatoire après la longueur minimale, ce qui entraîne la création de plusieurs comptes à privilèges élevés. Cette vulnérabilité est critique, mais elle peut être évitée si vous prenez certaines précautions de sécurité, telles que l'activation du mode strict pour les entrées utilisateur et la définition du champ sensible comme clé primaire dans la base de données.
