Zunächst ist mir klar, dass parametrisierte Abfragen die beste Option sind, aber ich frage mich, was die Strategie, die ich hier vorstelle, anfällig macht. Die Leute bestehen darauf, dass die folgende Lösung nicht funktioniert, also suche ich ein Beispiel, warum es nicht funktioniert.

Welche Art von Injection kann dies verhindern, wenn dynamischer SQL-Code mithilfe der folgenden Escapezeichen erstellt wird, bevor er an einen SQL Server gesendet wird?

string userInput= "N'" + userInput.Replace("'", "''") + "'"

Eine ähnliche Frage wurde beantwortetHier, aber ich glaube nicht, dass die Antworten hier zutreffen.

Es ist in SQL Server nicht möglich, das einfache Anführungszeichen mit einem "\" zu ersetzen.

Ich glaubeSQL-Schmuggel mit Unicode (skizziertHier) würde durch die Tatsache vereitelt, dass die erzeugte Zeichenfolge durch das N vor dem einfachen Anführungszeichen als Unicode gekennzeichnet ist. Soweit ich weiß, gibt es keine anderen Zeichensätze, die SQL Server automatisch in ein einfaches Anführungszeichen übersetzen würde. Ohne ein einfaches Anführungszeichen glaube ich nicht, dass eine Injektion möglich ist.

Ich glaube nichtString-Kürzung ist auch ein brauchbarer Vektor. SQL Server wird sicherlich nicht das Abschneiden durchführen, da die maximale Größe für einnvarchar beträgt 2 GBlaut microsoft. Eine 2-GB-Zeichenfolge ist in den meisten Situationen nicht möglich und in meiner unmöglich.

Injektion zweiter Ordnung möglich sein könnte, aber ist es möglich, wenn:

Alle in die Datenbank eingehenden Daten werden mit der oben beschriebenen Methode bereinigtWerte aus der Datenbank werden niemals an dynamisches SQL angehängt (warum sollten Sie das überhaupt tun, wenn Sie nur auf den Tabellenwert im statischen Teil einer dynamischen SQL-Zeichenfolge verweisen können?).

Ich schlage nicht vor, dass dies besser als oder eine Alternative zur Verwendung parametrisierter Abfragen ist, aber ich möchte wissen, wie anfällig das ist, was ich dargelegt habe. Irgendwelche Ideen?