Schutz der eingegebenen Daten gegen schlechtes Verhalten

Question

Für einige Funktionen innerhalb unserer ASP.NET (gegen SQL Server) -App erlauben wir den Mitarbeitern, eine WHERE-Klausel anzugeben. Diese WHERE-Klausel wird dann in Code an eine vom System generierte SELECT-Anweisung angehängt, um einige Daten abzurufen.

Also im Grunde haben wir am Ende oben mit:

SELECT SomeFields FROM Sometable WHEREUserEnteredWhere

wo die fett das System und die kursiv der Benutzer . Dies funktioniert seit einiger Zeit und gibt uns eine gute Flexibilität.

aber es ist eindeutig ein großes Problem hier, wo, wenn ein Benutzer eingibt:

somefield = 1; DROP TABLE SomeTable;

Derzeit ist die einzige Validierung, ob die Anweisung mit einer SELECT beginnt die passieren, weil wir mit am Ende werden:

SELECT SomeFields FROM Sometable WHEREsomefield = 1; DROP TABLE SomeTable;

Die langfristige Lösung wäre nicht der Benutzer zu ermöglichen, SQL in ein Textfeld eingeben, aber auf kurze Sicht mag ich dies zu untermauern.

Die einzige Lösung, die ich mir vorstellen kann, besteht darin, jede Anfrage in einer Transaktion auszuführen, um sicherzustellen, dass kein langfristiger Schaden entsteht.

Hat jemand irgendwelche Vorschläge, wie ich die vom Benutzer eingegebene "Where-Klausel" validieren kann, um sicherzustellen, dass sie keinen DDL-Inhalt hat, noch bevor sie ausgeführt wird?

PS. Ich weiß, dass das oben genannte schlecht ist und nicht gemacht werden sollte, aber es ist das, was ich in einem Legacy-System habe (ich habe nicht geschrieben). Bitte versuche mir zu helfen, anstatt mir zu sagen, tu das nicht. :-)

Answer 1

Da ich eine schnelle Lösung brauchte ich diese von der SQL Server-Seite der Dinge letztlich endete die Bekämpfung:

• Verwendung einer separaten Verbindung in .NET für diese Datenbank Wechselwirkungen Durch die.
T
• Der Benutzer gesperrt ist nur für SELECT Aussagen lassen sich wie folgt:

SQL:

CREATE LOGIN MrReadOnly 
    WITH PASSWORD = 'LetMeIn!'; 

USE MyDatabase; 
CREATE USER MrReadOnly FOR LOGIN MrReadOnly; 
GO 

EXEC sp_addrolemember N'db_datareader', N'MrReadOnly' 

Answer 2

Sie kennen die richtige Antwort - Sie haben Ihre Anwendung der SQL-Injektion ausgesetzt. Im Allgemeinen sind Ad-hoc-Lösungen nicht robust. Und die Aussage in eine Transaktion zu setzen, hilft nicht. Schließlich könnte commit einer der Befehle sein.

Einige Schnittstellen haben das Äquivalent von "eine einzelne Abfrage ausführen". Das würde Ihr Problem ziemlich lösen, weil eine zweite Abfrage einen Fehler in der Anwendung erzeugen würde.

Ich würde vorschlagen, keine der folgenden Zeichen/Wörter in den nutzergenerierten Bedingungen erlaubt:

• ;
• update
• delete
• insert
• create
• exec
• grant
• und möglicherweise mehr
• und möglicherweise auch select (es sei denn, Sie wollen Subqueries unterstützen)

Dies könnte zu einem gewissen Grad begrenzen, was für den Zustand erlaubt ist.

Dies ist keine Garantie gegen die Injektion, aber etwas, das die Dinge besser machen sollte.