Sicherheit für Datenbankverbindung

[Dagobert]

Guten Abend,
Ich habe hier vor einiger Zeit gelesen das man Java Programme sehr simpel und fast Vollständig wieder ein Quellcode umwandeln kann. Das hat mich zu der Überlegung gebracht, wie ich in meinem Programm eine Sichere SQL Verbindung beibringen kann. Ich haben im Quellcode die Verbindungsdaten hinterlegt, jetzt kann doch jeder kommen und meine Datenbank plätten oder sehe ich das Falsch?!
Wie kann ich das umgehen.

mfg. Dagobert

 

[Schandro]

Jep, Passwörter im Quellcode hinterlegen geht garnicht.

Wie wärs, wenn die Application sich mit nem Server verbinden muss und dieser ihm die Daten für die Datenbank schickt? Internetverbindung muss der Benutzer ja eh haben um sich mit der Datenbank zu verbinden...

 

[JohannisderKaeufer]

Wie wärs, wenn die Application sich mit nem Server verbinden muss und dieser ihm die Daten für die Datenbank schickt? Internetverbindung muss der Benutzer ja eh haben um sich mit der Datenbank zu verbinden...

Und wie stellst du sicher, dass es das richtig Programm ist, das beim Server nach der Verbindung fragt? Authentifizieren kann es sich ja nicht, da Authentifizierungsdaten im Programm, quasi offen daliegen würden.

Das man die Daten nicht durch eine maninthemiddle-Attacke ausspäht?

Unter Umständen kommt man sogar ohne Decompiler an eine Datenbankverbindung um diese "zu plätten".

 

[Schandro]

€dit: Ich hab ziemlich wenig Ahnung vom Thema Sicherheit in Software, deswegen schreib ich lieber gar nichts dazu 😉

 

[maki]

Und wie stellst du sicher, dass es das richtig Programm ist, das beim Server nach der Verbindung fragt? Authentifizieren kann es sich ja nicht, da Authentifizierungsdaten im Programm, quasi offen daliegen würden.

Wenn der User sich selbst Authentifizieren muss (und keine Daten im Programm hinterlegt sind) stellt sich dieses Problem nicht.

Das man die Daten nicht durch eine maninthemiddle-Attacke ausspäht?

Das ist etwas für den Bereich Netzwerksicherheit.

Unter Umständen kommt man sogar ohne Decompiler an eine Datenbankverbindung um diese "zu plätten".

Meinst du die "Schwachstelle Mensch" im allgemeinen oder wie jetzt..

 

[Dagobert]

hm...
also kann ich das Vergessen, dass ich eine Tabelle in der Datenbank habe, wo Benutzer und Passwort gespeichert sind, um eine Benutzerkontrolle in einem Programm zu machen, also Praktisch wie die Anmeldung hier im Forum nur als Java App ?

Oder gibt es dazu noch eine andere möglichkeit? Ich habe keine lust 1000 Datenbankkonten zu haben 😀

mfg. Dagobert

 

[Schandro]

Was soll das Client Programm den genau mit der Datenbank anfangen?
Vllt. kannst du ja in deiner Datenbank ansich ein 2. Zugangsaccount anlegen der nur das Recht hat bestimmte Daten zu lesen. Der Zugang zu diesem Account könnte dann ja auch im Quellcode drinstehen

 

[faulelotte]

Ein paar Sachen fielen doch schon. Du erstellst halt eine 3 Tier Anwendung.
Der Client verbindet sich unter Angabe von Username und Passwort mit einem Server und der quatscht als einziger direkt mit der Datenbank. In der Datenbank wird für die Applikation nur ein User mit Berechtigung beschränkt so weit wie nötig eingerichtet. Und falls du die Kommunikation zwischen Client und Server gegen Man-In-the-Middle Angriffe sichern willst, wozu gibts z.B. SSL ?

MfG FauleLotte

 

[Dagobert]

Also ich möchte ein Programm schreiben, was verschiedene User zulässt. Diese Benutzer sollen Daten lesen und editieren können, aber nicht löschen können. Das wollte ich mit einer Tabelle Benutzer machen wo Passwörter usw. hinterlegt sind.

mfg. Dagobert

 

[JohannisderKaeufer]

Meinst du die "Schwachstelle Mensch" im allgemeinen oder wie jetzt..

Nö, das meinte ich so nicht. Bei JDBC-Anwendungen habe ich schon einige male gesehen, das man ein Singelton erstellt, das die Datenbankverbindung hält und eine Methode anbietet die eine Connection zu eben jener zurückliefert.

Wenn ich (als Ganove) also eine Verbindung zu einer Datenbank möchte, könnte ich mir diese Klasse besorgen, eine Connection holen, und damit ganz ganz böse Statements an die DB schicken (z.B. dodelete AllTables, and shutdown, and create trigger, that does the same oder so :bahnhof🙂.

 

[maki]

Nö, das meinte ich so nicht. Bei JDBC-Anwendungen habe ich schon einige male gesehen, das man ein Singelton erstellt, das die Datenbankverbindung hält und eine Methode anbietet die eine Connection zu eben jener zurückliefert.

Wenn ich (als Ganove) also eine Verbindung zu einer Datenbank möchte, könnte ich mir diese Klasse besorgen, eine Connection holen, und damit ganz ganz böse Statements an die DB schicken (z.B. dodelete AllTables, and shutdown, and create trigger, that does the same oder so :bahnhof🙂.

Wenn du als "Ganove" Zugang zur der Klasse/zum Objekt hast welches die Db Verbindungen aufbaut dann stimmt etwas ganz und gar nicht mit dem Deisgn.

 

[sparrow]

Also ich möchte ein Programm schreiben, was verschiedene User zulässt. Diese Benutzer sollen Daten lesen und editieren können, aber nicht löschen können. Das wollte ich mit einer Tabelle Benutzer machen wo Passwörter usw. hinterlegt sind.

Hallo Dagobert,

irgendwann schickst du ja Benutzernamen und Password an die Datenbank. Jetzt hast du IMHO zwei Möglichkeiten:

1) Du gehst das größere Risiko ein und der angemeldete Benutzer auf der Datenbank darf alles und nur die Programmlogik entscheidet ob der im Programm angemeldete Benutzer zugelassen ist und was er darf. Die Probleme dieser Version wurden hier bereits genannt.

2) Jede moderne Datenbank kann Benutzer (Rollen) verwalten. Warum überlässt du es nicht der Datenbank ihre Stärken auszuspielen? Der Benutzer ist also entsprechender Benutzer auf der Datenbank, hier kann man auch schön für jede Tabelle/View einstellen welche Rechte er hat, etc.

Gruß
Sparrow

 

[Dagobert]

Guten Abend,

erstmal vielden Dank für eure Hilfe.
Ich werde mich dann jetzt mal mit dem Usermanagment ohne GUI vertraut machen.
Habe mich dazu entschlossen für jeden Benutzer des Programms auch ein eigenen Datenbankuser zu erstellen.

mfg. Dagobert

 

[tfa]

Habe mich dazu entschlossen für jeden Benutzer des Programms auch ein eigenen Datenbankuser zu erstellen.

Diese Lösung finde ich auch problematisch. Überlege dir, ob du die Berechtigungen für deine Anwendung damit sicher regeln kannst. Du kannst zwar sagen, Benutzer X hat auf Tabelle Y die Rechte insert, update und select. Aber das gilt dann für alle Daten in dieser Tabelle. Er könnte auch Datensätze lesen oder verändern, auf die er eigentlich keinen Zugriff haben sollte. Sicherlich könnte man das auch mit speziellen Views oder STPs umgehen. Das würde die Sache aber noch aufwendiger machen.

Meiner Meinung ist die einzig praktikable Lösung eine 3-Tier-Anwendung mit Client und Server.

 

[Ebenius]

Meiner Meinung ist die einzig praktikable Lösung eine 3-Tier-Anwendung mit Client und Server.

Ich hab eben nochmal das Thema überflogen... Es mag die einzige Lösung sein; aber augenscheinlich nicht für des Themeneröffners Problem... ???:L

Ebenius

 

[tfa]

Ich hab eben nochmal das Thema überflogen... Es mag die einzige Lösung sein; aber augenscheinlich nicht für des Themeneröffners Problem... ???:L

Ach...? ???:L

 

[Ebenius]

Ach...? ???:L

Der Themeneröffner schreibt:

Also ich möchte ein Programm schreiben, was verschiedene User zulässt. Diese Benutzer sollen Daten lesen und editieren können, aber nicht löschen können.

Das kann er ohne 3-Tier-App lösen. Pauschal lässt sich nicht sagen: "[...] die einzig praktikable Lösung [...]", wenn man nicht auf die konkreten Anforderungen eingeht. Oder?

Ebenius

 

[tfa]

Der Themeneröffner schreibt:
Das kann er ohne 3-Tier-App lösen.

Ohne die Anforderungen genauer zu kennen, kann man das wohl kaum entscheiden. Siehe oben.

 

[Dagobert]

Guten Morgen,

ich habe gestern angefangen daraus mal wieder ein Client-Server-Konzept zu basteln mithilfe von SIMON.
Also im Server werden die Anmeldedaten für die Datenbank hinterlegt (User, PW).
Der Server ist das einzige Objekt das direkt mit der Datenbank kommunitzieren soll.
Dann der Client der alle Querrys zum Server schickt und der die (falls möglich, Benutzerrechte es zulassen) results zurückschickt.
So habe ich mir das jetzt ungefähr vorgesllt.

mfg. Dagobert

 

[tuxedo]

OT: Und noch ein "glücklicher" SIMON User *yeeehaa*