Super Ansatz

[Der braune Lurch]

Statt solche nötigen Sicherheitsfunktionen in jedes SQL zu implementieren, einen Proxy einzurichten.

------------------------------
Der Molch macht's.
------------------------------
How much money have you spent on League of Legends?

[^Andreas Meisenhofer^]

Der braune Lurch schrieb:
--------------------------------------------------------------------------------
> <Aoi-chan> everyone's first vi session. ^C^C^X^X^X^XquitqQ!qdammit[esc]qwertyuiopasdfghjkl;:xwhat

*G*

-------------------------------------------------------
"We're semi-trained quasi-professionals, at any rate."

[visum]

ESC:q!

[Siga2439742]

Manche SQL-Server werden vielleicht von mobilen Vertretern/Wartungs-Fahrern o.ä. dynamisch zugegriffen. Da macht ein Proxy vielleicht doch Sinn.

Normalerweise würde ich aber vermuten, das nur der Webserver mit PHP oder der Java EE-Server o.ä. mit einer fixen IP auf den SQL-Server zugreifen darf und alles andere gesperrt ist.
Im Prinzip würde man die Ports auch sperren.

So ein Proxy macht also eher für dynamische Client-IPs Sinn oder wo man nicht gewährleisten kann, das sich jemand in die Filiale in Pusemuckel einbricht und Scannertools auf die Datenbank in der Zentrale laufen lässt.
Sowas sind reale Szenarios die nicht so einfach (VNC, Citrix,...) anders zu realisieren sind und es vielleicht auch nicht brauchen wenn z.b.: jede Filiale holt nachts die neuen Preise und tagsüber nur Updates falls nötig und nach dem Preis-Download ist jede Filiale autonom und die Leitung kann auch ausfallen.

Jede Seite könnte den Warenbestand bzw. neue Preise und Produkt-Infos natürlich auch als xml-Upload(Warenbestand)/xml-Broadcast(Preise/Sonderangebote/...) austauschen.
XML überschreitet aber vielen ihre Fähigkeiten.
Die proggern lieber wie ich vor 20 Jahren/wie Neandertaler.

[genauerhinlesen]

Ich glaub, hier wurde das Wort Proxy von Siga2439742 falsch verstanden. Die Software ist kein Netzwerkproxy, sondern analysiert die eingehenden Queries auf Datenbanken. Alles was verdächtig ist (mögliche SQL Injection, etc.) wird eben geblockt.

[schumischumi]

also von der art her auch intrusion detection?

[Dunkelelf]

Jo, wenn man sich die Screenshots ansieht sieht man das auch nochmal genauer. Man kann das Dingen eher wie eine SQL Firewall sehen, die nur Queries durchlässt die als sicher einzustufen sind. Das alles auf DB Ebene konfigurierbar und mit learning mode falls der Admin keine Ahnung hat welche Queries eigentlich vorkommen.

Für mich ein durchaus überlegenswerter Schritt den Zugriff auf den DB Server nochmals zu filtern. Denn seien wir mal ehrlich, die Probleme für SQL Injections liegen normalerweise nicht am DB Server, sondern an den schlecht programmierten Webapplikationen.

[Dunkelelf]

Der braune Lurch schrieb:
--------------------------------------------------------------------------------
> Statt solche nötigen Sicherheitsfunktionen in jedes SQL zu implementieren,
> einen Proxy einzurichten.


Erst nachdenken, dann posten. Viele SQL Injections verstoßen nicht gegen die Sicherheit des Datenbankservers. Es sind valide Queries die ein valides Ergebnis produzieren. Das Problem liegt in den schlecht programmierten Webanwendungen. Wenn ich mit einem in das Passwortfeld eingegebenen SQL Statement die Admin Kennwörter neusetzen kann, ist das kein Fehler vom DB Server sondern von der App die die Eingabewerte keiner Plausibilitätsprüfung unterzieht.

Wenn der Bauer nicht schwimmen kann liegts ja auch nicht an der Badehose...

Für einen Webhoster kann es somit durchaus sinnvoll sein so eine SQL Firewall zu etablieren.

[Der braune Lurch]

War ja auch keine Ironie, sondern eine echte Anerkennung.

------------------------------
Der Molch macht's.
------------------------------
How much money have you spent on League of Legends?

[Verwundert]

Siga2439742 schrieb:
--------------------------------------------------------------------------------
> Manche SQL-Server werden vielleicht von
> mobilen Vertretern/Wartungs-Fahrern
> o.ä. dynamisch zugegriffen.
> Da macht ein Proxy vielleicht doch Sinn.

Kind es geht um eine Application-Firewall und nicht um einen zentralen Zugriff für irgendwelche Deppen

[Fachwisser]

> Denn seien wir mal ehrlich, die Probleme für SQL Injections
> liegen normalerweise nicht am DB Server, sondern an den
> schlecht programmierten Webapplikationen.

Na alles andere wäre ja sowieso Unfug, denn woher soll ein DB Server wissen, welches SQL "gut" und welches "böse" ist.
Gerade dieses semantische Klassifizierung kann ein DB-Server per se erst einmal nicht leisten.

Trotzdem halte ich einen Proxy nur bedingt für notwendig. Normalerweise sollte der Zugriff auf die Datenbank sowieso auf ein Minimum reduziert sein, so dass z.B. nicht alle Nutzer alle Rechte haben bzw. nicht auf allen Tabellen etc.
Und solange der Zugriff von außen ohnehin nur durch eine Applikation erfolgen kann, ist es sowieso die Pflicht der Anwendung, Eingabewerte zu validieren.

Ich befürchte, bei Einsatz einer Proxylösung kann es passieren, dass man sich nur noch darauf verlässt und andere Sicherheitsmechanismen außer Acht lässt ("auf SQL Injection brauchen wir nicht prüfen, das macht der Proxy"). Außerdem holt man sich eine weitere Schicht in die Anwendung, was den Datenbankzugriff nicht schneller macht.

[fjghdkjghd]

Mal folgendes Beispiel:

Benutzer können über das Webinerface einer Anwendung CRUD Operationen durchführen. Also brauchen Sie die SELECT, UPDATE, INSERT, DELETE Rechte. Jetzt hat man schlampig gearbeitet und irgendwo ist eine SQL-Injection möglich, über die einer zum Spass den Befehl:
SELECT * FROM table1; DELETE FROM table2 jagt.
Schon ist table2 leer. Wenn man aber eine Whitelist hat und nur erlaubt:

DELETE FROM table2 WHERE id = ?

dann hilft das den Schaden zu minimieren, da immer nur ein Datensatz auf einmal gelöscht werden kann.
Ausserdem finde ich den Ansatz pauschal alles zu blocken und gezielt nur das zu erlauben was man braucht sehr gut.

[Verwundert]

fjghdkjghd schrieb:
---------------------------------------------------------------------------
> Ausserdem finde ich den Ansatz pauschal alles
> zu blocken und gezielt nur
> das zu erlauben was man braucht sehr gut.

Lass mich raten:
Aber administrieren geschweige denn um die Perobleme herum programmieren willst du nicht

Das Zeug ist für Dummköpfe und Fremdanwednungen und ansonsten nure ine massive Fehlerquelle deren letztliche Konsequenzen kaum eingeschätzt werden lönnen wenn in einer 100% durchgetesteten Awendung plötzlich Queryies nicht mehr bei der DB ankommen