Non, il n'y a pas de longueur trop courte pour être exploitable (du moins dans certaines situations).
Un filtre de longueur n'est pas une protection valide contre l'injection SQL, et les instructions préparées sont vraiment les seulement une défense correcte.
Un filtre de longueur est cependant une bonne mesure comme défense en profondeur (tout comme les filtres entiers, les filtres alphanum, etc.). Il existe de nombreuses situations où, par ex. une entrée valide ne peut jamais dépasser, disons, 30 caractères, mais là où une exploitation significative nécessite plus. Cela devrait (mais probablement pas) aller sans dire que tout filtrage en tant que défense en profondeur doit avoir lieu côté serveur, car tout ce qui est côté client peut simplement être contourné.
Contournement de restriction
Les clauses de restriction (par exemple AND
/ OR
) peuvent être contournées par deux caractères, ce qui peut causer un préjudice réel, pas seulement une requête échouée. L'exemple le plus simple est un login (d'autres exemples seraient la suppression non autorisée de données supplémentaires):
SELECT * FROM utilisateurs WHERE userid = [id] AND password = [password]
Injection:
id = 1 # password = mot de passe incorrect
Charge utile: 2 caractères
DoS
Les attaques DoS nécessitent très peu de caractères. Dans un exemple MySQL, il faut 7 pour l'appel réel + x pour les secondes données + tout ce qui est nécessaire pour pouvoir appeler la fonction et corriger la requête.
Exemple:
SELECT * FROM utilisateurs WHERE userid = [id]
Injection (il s'agit d'une injection valide, une forme plus longue serait 1 AND sleep (99)
):
sleep (99)
Charge utile: 9 caractères
Lecture des données
Si les données s'affiche, la longueur dépend principalement du nom de la table et de la colonne. Je suppose que le nombre de colonnes est égal pour toutes les tables (cela peut arriver et cela enregistre les caractères).
Exemple:
SELECT * FROM commentaires WHERE commentid = [id]
Injection:
1 union select * parmi les utilisateurs
Charge utile: 27 caractères.
Modification des données
Des modifications non autorisées de la base de données peuvent également être effectuées avec quelques caractères.
Exemple:
UPDATE users SET password = '[password]' WHERE id = [id]
Injection (dans le mot de passe):
', isadmin =' 1
Charge utile: 12 caractères
Un contournement de restriction fonctionnerait également (le résultat est que tous les mots de passe sont maintenant vides *):
'#
Charge utile: 2 caractères
* L'exemple de mot de passe est utilisé par souci de simplicité; les mots de passe doivent être hachés, ce qui rend l'exemple impossible. L'exemple s'applique toujours dans toutes les situations similaires (mise à jour d'un nom d'utilisateur, mise à jour des autorisations, etc.)