L'injection SQL
Comment une saisie collée dans une requête change cette requête : connexion contournée, lecture d'autres tables par UNION, destruction ; la requête préparée, le moindre privilège du compte SQL et les fausses parades.
- 24 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Injection SQL : de quoi s'agit-il ?
Voir la réponse
Attaque où une saisie, collée telle quelle dans une requête, est lue par la base comme du code SQL et non comme une simple valeur.
Le défaut vient de la construction de la requête par concaténation : la base ne sait pas où s'arrête le code du programmeur et où commence la saisie.
Le site construit la requête SELECT * FROM users WHERE login = '<saisie>' AND pwd = '<mot de passe>'. Un visiteur saisit ' OR '1'='1 comme mot de passe pour le login alice. Que fait la base ?
- Elle renvoie toutes les lignes, car la condition finale est toujours vraie
- Elle refuse la requête et lève une erreur de syntaxe, car l'apostrophe ferme mal la chaîne
- Elle ne renvoie que la ligne d'alice, dont le mot de passe n'est plus comparé du tout
- Elle renvoie zéro ligne, car la chaîne OR n'est pas un mot de passe
Voir la réponse
Elle renvoie toutes les lignes, car la condition finale est toujours vraie
La requête reçue est ... WHERE login = 'alice' AND pwd = '' OR '1'='1'. AND passe avant OR : la condition vaut (login = alice AND pwd vide) OR (toujours vrai), donc toutes les lignes sont renvoyées, et le programme connecte en général la première, souvent l'administrateur.
Une injection SQL devient possible quand le programme construit la requête par … de texte avec une saisie non contrôlée.
Voir la réponse
Une injection SQL devient possible quand le programme construit la requête par concaténation de texte avec une saisie non contrôlée.
C'est cette colle entre code et saisie qui est fautive : filtrer la saisie ne la répare pas, séparer le code et les valeurs oui.
Requête préparée : de quoi s'agit-il ?
Voir la réponse
Requête envoyée à la base avec des marqueurs à la place des valeurs, puis exécutée avec les valeurs fournies à part.
La structure est fixée avant l'arrivée de la saisie : quoi que contienne celle-ci, elle ne peut plus changer la forme de la requête.
Le journal du serveur montre des requêtes vers article.php?id=1 AND 1=1, puis id=1 AND 1=2, puis id=1 UNION SELECT NULL. La page change selon la condition. Que se passe-t-il, et que faut-il corriger ?
- Un sondage d'injection SQL : remplacer la concaténation de id par une requête préparée
- Un robot d'indexation normal : limiter simplement son débit de requêtes et laisser faire
- Une attaque par déni de service : ajouter un pare-feu devant le serveur web et la base
- Une erreur de cache : vider le cache de la page à chaque requête reçue par le serveur
Voir la réponse
Un sondage d'injection SQL : remplacer la concaténation de id par une requête préparée
Que la page réagisse à AND 1=1 et AND 1=2 prouve que la saisie est interprétée comme du SQL. L'attaquant mesure la faille avant de lire des données. La réparation est dans le code : requête préparée, id converti en entier.