Il y a quelques cas où cette fonction d'échappement échouera. Le plus évident est lorsqu'un seul guillemet n'est pas utilisé :
string table= "\"" + table.Replace("'", "''") + "\""
string var= "`" + var.Replace("'", "''") + "`"
string index= " " + index.Replace("'", "''") + " "
string query = "select * from `"+table+"` where name=\""+var+"\" or id="+index
Dans ce cas, vous pouvez "éclater" en utilisant un guillemet double, un back-tic. Dans le dernier cas, il n'y a rien à "éclater", vous pouvez donc simplement écrire 1 union select password from users-- ou quelle que soit la charge utile sql souhaitée par l'attaquant.
La condition suivante où cette fonction d'échappement échouera est si une sous-chaîne est prise après que la chaîne a été échappée (et oui J'ai trouvé des vulnérabilités comme celle-ci dans la nature) :
string userPassword= userPassword.Replace("'", "''")
string userName= userInput.Replace("'", "''")
userName = substr(userName,0,10)
string query = "select * from users where name='"+userName+"' and password='"+userPassword+"'";
Dans ce cas, un nom d'utilisateur de abcdefgji' sera transformé en abcdefgji'' par la fonction d'échappement puis redevenu abcdefgji' en prenant la sous-chaîne. Cela peut être exploité en définissant la valeur du mot de passe sur n'importe quelle instruction sql, dans ce cas or 1=1-- serait interprété comme sql et le nom d'utilisateur serait interprété comme abcdefgji'' and password= . La requête résultante est la suivante :
select * from users where name='abcdefgji'' and password=' or 1=1--
T-SQL et d'autres techniques d'injection sql avancées ont déjà été mentionnées. Injection SQL avancée dans les applications SQL Server est un excellent document et vous devriez le lire si vous ne l'avez pas déjà fait.
Le dernier problème concerne les attaques unicode. Cette classe de vulnérabilités survient parce que la fonction d'échappement n'est pas consciente du codage multi-octets, et cela peut être utilisé par un attaquant pour "consommer" le caractère d'échappement. Ajouter un "N" à la chaîne n'aidera pas, car cela n'affecte pas la valeur des caractères multi-octets plus loin dans la chaîne. Cependant, ce type d'attaque est très rare car la base de données doit être configurée pour accepter les chaînes Unicode GBK (et je ne suis pas sûr que MS-SQL puisse le faire).
L'injection de code de second ordre est toujours possible, ce modèle d'attaque est créé en faisant confiance aux sources de données contrôlées par l'attaquant. L'échappement est utilisé pour représenter les caractères de contrôle comme leur caractère littéral. Si le développeur oublie d'échapper une valeur obtenue à partir d'un select puis utilise cette valeur dans une autre requête puis bam l'attaquant aura à sa disposition un guillemet simple littéral de caractère.
Testez tout, ne faites confiance à rien.
