Es gibt einige Fälle, in denen diese Escape-Funktion fehlschlägt. Am offensichtlichsten ist es, wenn kein einfaches Anführungszeichen verwendet wird:
string table= "\"" + table.Replace("'", "''") + "\""
string var= "`" + var.Replace("'", "''") + "`"
string index= " " + index.Replace("'", "''") + " "
string query = "select * from `"+table+"` where name=\""+var+"\" or id="+index
In diesem Fall können Sie mit einem doppelten Anführungszeichen, einem Backtick, „ausbrechen“. Im letzten Fall gibt es nichts zu "ausbrechen", also können Sie einfach 1 union select password from users-- schreiben oder welche SQL-Nutzlast der Angreifer wünscht.
Die nächste Bedingung, bei der diese Escape-Funktion fehlschlägt, ist, wenn eine Teilzeichenfolge genommen wird, nachdem die Zeichenfolge mit Escapezeichen versehen wurde (und ja Ich habe Sicherheitslücken wie diese in freier Wildbahn gefunden):
string userPassword= userPassword.Replace("'", "''")
string userName= userInput.Replace("'", "''")
userName = substr(userName,0,10)
string query = "select * from users where name='"+userName+"' and password='"+userPassword+"'";
In diesem Fall ein Benutzername von abcdefgji' wird in abcdefgji'' umgewandelt durch die Escape-Funktion und dann wieder in abcdefgji' umgewandelt indem Sie den Teilstring nehmen. Dies kann ausgenutzt werden, indem der Passwortwert auf eine beliebige SQL-Anweisung gesetzt wird, in diesem Fall or 1=1-- würde als sql interpretiert und der Benutzername würde als abcdefgji'' and password= interpretiert . Die resultierende Abfrage lautet wie folgt:
select * from users where name='abcdefgji'' and password=' or 1=1--
T-SQL und andere fortgeschrittene SQL-Injection-Techniken wurden bereits erwähnt. Advanced SQL Injection in SQL Server Applications ist ein großartiges Dokument, und Sie sollten es lesen, wenn Sie es noch nicht getan haben.
Das letzte Problem sind Unicode-Angriffe. Diese Klasse von Sicherheitslücken entsteht, weil die Escape-Funktion die Multi-Byte-Codierung nicht kennt und dies von einem Angreifer verwendet werden kann, um das Escape-Zeichen zu „verbrauchen“. Es hilft nicht, der Zeichenfolge ein "N" voranzustellen, da dies den Wert von Multibyte-Zeichen später in der Zeichenfolge nicht beeinflusst. Diese Art von Angriff ist jedoch sehr ungewöhnlich, da die Datenbank so konfiguriert werden muss, dass sie GBK-Unicode-Strings akzeptiert (und ich bin mir nicht sicher, ob MS-SQL dies kann).
Das Einschleusen von Code zweiter Ordnung ist weiterhin möglich, dieses Angriffsmuster wird durch Vertrauen in angreifergesteuerte Datenquellen erstellt. Escaping wird verwendet, um Steuerzeichen als ihr Zeichenliteral darzustellen. Wenn der Entwickler vergisst, einen Wert zu maskieren, der von einem select erhalten wurde und verwendet dann diesen Wert in einer anderen Abfrage, dann bam Dem Angreifer steht ein einfaches Anführungszeichen zur Verfügung.
Alles testen, nichts vertrauen.
