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

Dies ist eine schlechte Idee, und zwar nicht nur aus der Sicht der Injektionsprävention. Es ist sehr einfach für einen Benutzer, der es nicht besser weiß, versehentlich eine Abfrage auszuführen, die alle Ihre Datenbankressourcen (Arbeitsspeicher und CPU) in Anspruch nimmt, was effektiv zu einem Denial-of-Service-Angriff führt.

Wenn Sie muss Um dies zu ermöglichen, ist es am besten, einen völlig separaten Server für diese Abfragen zu betreiben und ihn mit Hilfe der Replikation so nah wie möglich an einer exakten Spiegelung des Produktionssystems zu halten. Das funktioniert natürlich nicht mit Ihrer UPDATE-Anforderung.

Aber ich möchte noch einmal sagen: Das funktioniert einfach nicht. Sie können Ihre Datenbank nicht schützen, wenn die Benutzer Ad-hoc-Abfragen durchführen können.

Answer 2

Was ist mit diesem Zeug, stellen Sie sich einfach vor, der Select ist ein EXEC

select convert(varchar(50),0x64726F70207461626C652061)

Answer 3

Mein Gefühl sagt mir, dass Sie sich darauf konzentrieren sollten, die Kontoberechtigungen und Berechtigungen so eng wie möglich zu setzen. Schauen Sie sich die Sicherheitsdokumentation Ihres RDBMS gründlich an. Es kann durchaus sein, dass es Funktionen gibt, mit denen Sie nicht vertraut sind und die sich als hilfreich erweisen würden (ich glaube, dass z. B. Oracles Virtual Private Database in dieser Art von Szenario nützlich sein kann).

Insbesondere Ihre Idee "Überprüfen Sie (mit Regex), dass der Benutzer die Berechtigung hat, auf die Tabellen zuzugreifen, die abgefragt/aktualisiert werden, die in Joins enthalten sind usw." klingt, als würden Sie versuchen, die bereits in die Datenbank integrierte Sicherheitsfunktionalität neu zu implementieren.

Answer 4

Was Ihnen entgeht, ist der Einfallsreichtum eines Angreifers, der Lücken in Ihrer Anwendung findet.

Ich kann Ihnen praktisch garantieren, dass Sie nicht in der Lage sein werden, alle Löcher zu schließen, wenn Sie dies zulassen. Es könnte sogar Fehler in der Datenbank-Engine geben, von denen Sie nichts wissen, die aber dazu führen, dass eine SQL-Anweisung, die Sie für sicher halten, in Ihrem System Schaden anrichtet.

Kurz gesagt: Das ist eine denkbar schlechte Idee!

Answer 5

Nun, Sie haben schon genug Leute, die Ihnen sagen, dass Sie nicht in der Lage sind. "Tu das nicht" Wenn sie Sie also nicht davon abbringen können, haben wir hier ein paar Ideen:

Das Gute einbeziehen, nicht versuchen, das Schlechte auszuschließen
(Ich glaube, die richtige Terminologie lautet Whitelisting gegen Schwarze Liste ) Damit meine ich suchen Sie nicht nach bösen oder ungültigen Dingen, die Sie wegwerfen können (es gibt zu viele Möglichkeiten, es zu schreiben oder zu verschleiern), suchen Sie stattdessen nach gültige Angaben zu machen und werfen Sie alles andere weg.

Sie haben bereits in einem anderen Kommentar erwähnt, dass Sie nach einer Liste von benutzerfreundlichen Tabellennamen suchen und die tatsächlichen Schema-Tabellennamen ersetzen wollen. Genau das meine ich - wenn Sie das tun, dann tun Sie es auch mit Feldnamen.

Ich tendiere aber immer noch zu einer Art grafischer Benutzeroberfläche: Wählen Sie hier die Tabellen aus, die Sie anzeigen möchten, wählen Sie hier die Felder aus, die Sie sehen möchten, verwenden Sie einige Dropdowns, um eine Where-Klausel zu erstellen usw. Das ist mühsam, aber wahrscheinlich einfacher.