Wie verhindert man Sql-Injection bei benutzergenerierten Sql-Abfragen?

Question

Ich habe ein Projekt (privat, ASP.net-Website, passwortgeschützt mit https), wo eine der Anforderungen ist, dass der Benutzer in der Lage sein, Sql-Abfragen, die direkt die Datenbank abfragen wird eingeben. Ich muss in der Lage sein, diese Abfragen zuzulassen und gleichzeitig zu verhindern, dass sie die Datenbank selbst beschädigen und auf Daten zugreifen oder diese aktualisieren, auf die sie nicht zugreifen/aktualisieren können sollten.

Für die Umsetzung habe ich mir folgende Regeln ausgedacht:

1. Verwenden Sie einen db-Benutzer, der sólo hat die Berechtigung für Select Table/View und Update Table (alle anderen Befehle wie drop/alter/truncate/insert/delete werden also nicht ausgeführt).
2. Überprüfen Sie, ob die Anweisung mit den Worten "Select" oder "Update" beginnt.
3. Überprüfen Sie (mit Hilfe von Regex), dass in der Anweisung keine Semikolons vorkommen, die nicht von einfachen Anführungszeichen, Leerzeichen und Buchstaben umgeben sind. (Der Gedanke dabei ist, dass die einzige Möglichkeit, eine zweite Abfrage einzufügen, darin besteht, die erste mit einem Semikolon zu beenden, das nicht Teil einer Eingabezeichenfolge ist).
4. Überprüfen Sie (mit Hilfe von Regex), ob der Benutzer die Berechtigung hat, auf die Tabellen zuzugreifen, die abgefragt/aktualisiert, in Joins einbezogen werden, usw. Dies schließt alle Unterabfragen ein. (Dies wird u. a. dadurch erreicht, dass der Benutzer eine Reihe von Tabellennamen verwendet, die in der Datenbank nicht existieren; ein Teil des Abfrageparsings besteht darin, die korrekten entsprechenden Tabellennamen in der Abfrage zu ersetzen).

Habe ich etwas übersehen?

Das Ziel ist, dass die Benutzer in der Lage sein, Abfragen/Aktualisierungen von Tabellen, auf die sie Zugriff haben, auf jede beliebige Art und Weise, die sie für richtig halten, durchzuführen und alle versehentlichen oder böswilligen Versuche, die Datenbank zu beschädigen, zu verhindern.

Answer 1

Wenn sie nicht wirklich fortgeschrittene Abfragen durchführen müssen, könnten Sie eine Benutzeroberfläche bereitstellen, die nur bestimmte Auswahlmöglichkeiten zulässt, wie eine Dropdown-Liste mit "Aktualisieren, Löschen, Auswählen", dann würde die nächste ddl automatisch mit einer Liste der verfügbaren Tabellen usw. gefüllt.

In Ihrem serverseitigen Code würden Sie dann diese Gruppen von Oberflächenelementen in SQL-Anweisungen umwandeln und eine parametrisierte Abfrage verwenden, um bösartige Inhalte zu stoppen

Answer 2

Das ist eine schrecklich schlechte Praxis. Ich würde eine Handvoll gespeicherter Prozeduren erstellen, um alles zu erledigen, was Sie tun wollen, sogar die fortgeschrittenen Abfragen. Präsentieren Sie sie dem Benutzer, lassen Sie ihn die gewünschte Prozedur auswählen und übergeben Sie Ihre Parameter.

Die Antwort über meiner ist auch sehr gut.

Answer 3

Obwohl ich mit Joel Coehoorn und SQLMenace übereinstimme, haben einige von uns "Anforderungen". Anstatt sie Ad-hoc-Abfragen senden zu lassen, sollten Sie einen visuellen Query Builder erstellen, wie er in den MS-Beispielanwendungen auf asp.net zu finden ist, oder dies versuchen リンク .

Ich habe nichts gegen die von Joel vorgebrachten Argumente. Er hat Recht. Wenn Benutzer (wir sprechen hier von Benutzern, denen es egal ist, was Sie durchsetzen wollen) Abfragen stellen, ist das wie eine Anwendung ohne "Business Logic Layer", ganz zu schweigen von den zusätzlichen Fragen, die zu beantworten sind, wenn bestimmte Ergebnisse nicht mit anderen unterstützenden Anwendungsergebnissen übereinstimmen.

Answer 4

Hier ein weiteres Beispiel

der Hacker braucht den echten Tabellennamen nicht zu kennen, er/sie kann undokumentierte Procs wie diese ausführen

sp_msforeachtable 'print ''?''' 

nur statt drucken wird es fallen gelassen

Answer 5

Viele Antworten besagen, dass dies keine gute Idee ist, aber manchmal ist es das, worauf die Anforderungen bestehen. Es gibt jedoch ein Problem, das ich in den "Wenn Sie es trotzdem tun müssen"-Vorschlägen noch nicht entdeckt habe: Stellen Sie sicher, dass alle Aktualisierungsanweisungen eine WHERE-Klausel enthalten. Es ist nur allzu leicht, die

UPDATE ImportantTable
SET VitalColumn = NULL

und verpassen das Wichtige

WHERE UserID = @USER_NAME

Wenn eine Aktualisierung für die gesamte Tabelle erforderlich ist, ist es einfach genug, Folgendes hinzuzufügen

WHERE 1 = 1

Das Erfordernis der Where-Klausel hält einen böswilligen Benutzer nicht davon ab, schlechte Dinge zu tun, aber es sollte versehentliche Änderungen der gesamten Tabelle reduzieren.