DB Sicherheit in JAVA

[Guest]

Hallo zusammen!
Ich muss in der Schule eine Arbeit über Datenbank Sicherheit in JAVA schreiben. Also, welche Sicherheitslücken es bei Datenbanken allgemein gibt und wie man sie mit JAVA unter Umständen schließen kann. Ich hab google schon durchforstet aber finde irgendwie nichts...

Was ich von euch gerne hätte, ist kein fertiges Dokument, sondern eher Stichwörter oder Quellen (links oder auch Bücher) zu dem Thema.

Ich hätte einfach gerne einen Überblick über die Sicherheitsfunktionen in bezug auf Datenbanken (SQL Server, Oracle, MySQL und PostgresSQL) die JAVA bietet.

mfg

 

[hupfdule]

Entweder habe ich dich nicht richtig verstanden oder die Aufgabenstellung ist einfach Schwachsinn. Sicherheitslücken, die in einer Datenbank vorhanden sind, lassen sich nicht durch eine Programmiersprache ausgleichen. Von daher weiß ich nicht wirklich, was mit "Sicherheitsfunktionen, die Java bietet" gemeint ist.

 

[Yzebär]

Entweder habe ich dich nicht richtig verstanden oder die Aufgabenstellung ist einfach Schwachsinn. Sicherheitslücken, die in einer Datenbank vorhanden sind, lassen sich nicht durch eine Programmiersprache ausgleichen. Von daher weiß ich nicht wirklich, was mit "Sicherheitsfunktionen, die Java bietet" gemeint ist.

Manchmal sollte man erst nachdenken, bevor man postet. Man kann sehr wohl Sicherheitslücken einer Datenbank verstecken, wenn man dem User beschränkten Zugriff auf eine Datenbank über eine Java-Applikation gewährt und damit evtl vorhandene Lücken schon schließen kann, weil ich rein programmtechnisch gar nicht zulasse, daß die Lücke ausgenutzt wird.

Sicher bietet Java keine "eingebauten Sicherheitsfunktionen", aber Möglichkeiten sich selbst welche zu basteln. Das erste, das mir zu diesem Thema einfällt wäre Kryptographie.

Guck dir doch zunächst einmal an, was es für Sicherheitslücken gibt und beschäftige dich danach damit, wie du diese mit einer Java-Applikation vor dem User verstecken kannst.

 

[Guest]

Entweder habe ich dich nicht richtig verstanden oder die Aufgabenstellung ist einfach Schwachsinn. Sicherheitslücken, die in einer Datenbank vorhanden sind, lassen sich nicht durch eine Programmiersprache ausgleichen. Von daher weiß ich nicht wirklich, was mit "Sicherheitsfunktionen, die Java bietet" gemeint ist.

Ein Beispiel wäre SQL-Injection http://de.wikipedia.org/wiki/SQL_Injection. Kann in Java einfach verhindert werden....

@Yzebär: Gute Idee, danke. Werde das Problem mal so angehen.

 

[hupfdule]

Ein Beispiel wäre SQL-Injection http://de.wikipedia.org/wiki/SQL_Injection. Kann in Java einfach verhindert werden....

SQL-Injection ist aber keine Sicherheitslücke der Datenbank, sondern der Anwendung. Ich vermute also, dass das damit gemeint ist, wie man Datenbankanwendungen allgemein absichern kann.

Manchmal sollte man erst nachdenken, bevor man postet.

Du bist ja scheinbar gut drauf heute...

Man kann sehr wohl Sicherheitslücken einer Datenbank verstecken, wenn man dem User beschränkten Zugriff auf eine Datenbank über eine Java-Applikation gewährt und damit evtl vorhandene Lücken schon schließen kann, weil ich rein programmtechnisch gar nicht zulasse, daß die Lücke ausgenutzt wird.

Hmm, ich könnte mir das nur so vorstellen, dass man in der Anwendung z.B. keine SQL-Anweisungen benutzt, von denen bekannt ist, dass deren Implementierung in der DB fehlerhaft ist. Jedoch ist das nichts sprachspezifisches. Das kann man dann in jeder anderen Programmiersprache auch tun. Auch kommt mir der Fall eher etwas theoretisch vor.

Eine Beschränkung des Zugriffs auf die DB, um die Gefahr des Ausnutzens von Sicherheitslücken zu minimieren, nehme ich jedoch eher an der DB vor, indem ich dort Benutzer anlege, die nur die absolut nötigen Rechte habe. Damit erreiche ich eher das gegenteilige Ziel, nämlich, dass ich durch Funktionalität der Datenbank Sicherheitslücken der Anwendung ausgleiche.

Sicher bietet Java keine "eingebauten Sicherheitsfunktionen", aber Möglichkeiten sich selbst welche zu basteln. Das erste, das mir zu diesem Thema einfällt wäre Kryptographie.

Kryptopgraphie kann zusätzliche Sicherheit bieten. So auf Anhieb fällt mir jedoch nicht ein, wie Sicherheitslücken damit abgedeckt werden könnten.

 

[Guest]

SQL-Injection ist aber keine Sicherheitslücke der Datenbank, sondern der Anwendung. Ich vermute also, dass das damit gemeint ist, wie man Datenbankanwendungen allgemein absichern kann.

Ok, ich glaube das ist was der Prof will. klingt auch logischer als meine Erklärung. Danke!
Werd mal schaun was ich dazu finde.

 

[Gast]

Wobei, nicht Datenbankanwendungen allgemein, sondern schon Java-Anwendungen! Und dabei in Bezug auf die oben genannten DBs (Oracle, SQL Server, MySql, PostgresSQL)

 

[Yzebär]

Ich denke mal es gibt sehr wenige echte Sicherheitslücken in den Datenbanken selbst. Aber dem User zu ermöglichen beliebige Statements abzusetzen, gäbe ihm die natürlich auch die Möglichkeit einen potentiellen Bug voll auszunutzen. Da man nicht ausschließen kann, daß es einen Bug gibt (man kann ja nicht alle Statements testen, da es unendliche Möglichkeiten gibt Statements zu erstellen), kann man dies als potentielle Sicherheitslücke der Datenbank betrachten, die in der Anwendung versteckt werden muß. Das jetzt nur als Anregung, wie man sowas dem Prof. verkaufen kann...

Mit Kryptographie meinte ich folgendes. Es ist nicht ratsam sensible Daten unverschlüsselt in der Datenbank abzulegen. Zum einen kann ja die DB trotz aller Sicherheitsvorkehrungen mal gehackt werden, zum anderen werden die Daten aus der Datenbank über das Netzwerk zum User übertragen (oder umgekehrt) und könnten unterwegs abgehört werden. Zum Beispiel wenn Passwörter in der DB gespeichert sind.

Den Zugriff des User auf die DB beschränkt man am besten, wenn dieser keinen direkten Zugriff auf die DB hat und die Funktionalität meiner Applikation zum Auslesen und Speichern benutzen muß.

 

[Guest]

Ich denke mal es gibt sehr wenige echte Sicherheitslücken in den Datenbanken selbst. Aber dem User zu ermöglichen beliebige Statements abzusetzen, gäbe ihm die natürlich auch die Möglichkeit einen potentiellen Bug voll auszunutzen. Da man nicht ausschließen kann, daß es einen Bug gibt (man kann ja nicht alle Statements testen, da es unendliche Möglichkeiten gibt Statements zu erstellen), kann man dies als potentielle Sicherheitslücke der Datenbank betrachten, die in der Anwendung versteckt werden muß. Das jetzt nur als Anregung, wie man sowas dem Prof. verkaufen kann...

Und wie soll man das in der Anwendung verstecken? Ich meine wenn er ein beliebiges Statement absetzen kann kann ich ja eh nichts machen. Außer ihm die Rechte für verschiedene Dinge zu nehmen (was ich aber bei der DB mach...)

Den Zugriff des User auf die DB beschränkt man am besten, wenn dieser keinen direkten Zugriff auf die DB hat und die Funktionalität meiner Applikation zum Auslesen und Speichern benutzen muß.

OK, wenn er dann meine Funktionaltiäten benutzt, was muss ich dann noch in bezug auf Sicherheit tun? Außer vielleicht die Übertragung zu verschlüsseln?

Finden tu ich auch nichts... Bis auf SQL-Injection und Stored Procedures (beides ein Hinweis vom Prof.). Gibts da sonst noch irgendwelche Sicherheitslücken die auf Anwendungsseite und somit mit Java beseitigt werden können?

Danke für eure Hilfe!

mfg

 

[Gast]

Kann mir keiner Hinheise oder Tipps geben?

 

[Yzebär]

Und wie soll man das in der Anwendung verstecken? Ich meine wenn er ein beliebiges Statement absetzen kann kann ich ja eh nichts machen. Außer ihm die Rechte für verschiedene Dinge zu nehmen (was ich aber bei der DB mach...)

Er soll eben kein Statement selbst eingeben können, z.B. der User sieht eine Liste mit Tabellen (die er sehen darf) und kann irgendwelche Aktionen ausführen, die der Programmierer selbst festlegt (Inhalt ansehen, Datensatz ändern etc.). Alle Statements die abgesetzt werden dürfen, stehen in deinem Sourcecode (oder in Properties, die von deiner Applikation geladen werden).

Die Applikation verwaltet die Connections zur DB, d.h. der User hat keinen direkten Zugriff zur DB und damit auch keine eigene Connection. Dadurch kann die DB nicht blockiert werden, weil jemand mit zig Connections jede Menge Traffic generiert (ähnlich einer DoS(Denial of Service)-Attacke auf einen Webserver).

Guck mal hier (stored procedures):
archive.cert.uni-stuttgart.de/archive/win-sec-ssc
cert.uni-stuttgart.de/ticker

Was mir noch einfällt... beim MS SQL Server kann man auch Shell-Kommandos (als SQL Statement: xp_commandshell oder so) ausführen, die mit den Rechten des SQL Servers ausgeführt werden (SQL injection).

 

[Gast]

@Yzebär
Ok, ich wollt wissen wie man sowas in der Anwendung versteckt, wenn dem User die Möglichkeit gegeben werden muss beliebige Statements abzusetzen. (Im nachhinein denke ich aber nicht, dass es viele Anwendungen geben wird bei denen es erforderlich ist das der User irgenwelche Statements absetzen kann)

Aber wenn ich das dann so in der Anwendung verstecke wie du geschrieben hast, was muss dann noch zwecks Sicherheit getan werden? (Außer Kryptologie, und Sicherheit der Anwendung selbst)
Ich mein SQL-Injections fallen in dem Fall ja weg, oder versteh ich da was nicht?

 

[hupfdule]

Ich mein SQL-Injections fallen in dem Fall ja weg, oder versteh ich da was nicht?

Nein, SQL-Injections sind nur in diesem Fall relevant. Wer vollständige SQL-Anweisungen absetzen kann, brauch ja nix injizieren.
Aber du baust eine SQL-Anweisung zusammen. Teile davon nimmst du von den Eingaben des Benutzers. Und diese Eingaben müssen genau geprüft werden, damit keine SQL-Injection durchgeführt werden kann.

 

[Gast]

ok, stimmt, hab da irgenwie falsch gedacht... schon klar, danke

 

[Yzebär]

Beliebige Statements eingeben, heißt ja nicht, daß man das über ein Eingabefeld machen muß. Unser Unternehmen zB kann an Kunden SQL-Skripte (die irgendwas in der DB reparieren) verschicken und die Kunden müssen diese Skripte selbst ausführen (über Funktionalität unserer Anwendung). Dabei muß gesichert sein, daß der Kunde oder ein Dritter diese Skripte nicht verändert oder eigene Skripte einspielt.

Solche oder ähnliche Backdoors muß man sich ja immer offen halten, weil es durch Programmierfehler oder Anwenderfehler zu Problemen in der Datenbank kommt und man manuell eingreifen muß.