DB-Sicherheit und Java

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 10:26

Hallo zusammen!
Ich arbeite gerade an ner FBA zum Thema "DB-Sicherheit und Java". Also wie man DB-Zugriffe sicherer machen kann.

Zum einen beschäftige ich mit JSSE (also allgemeine Übertragungssicherheit) und DB-bezogen noch mit SQLInjections und Stored Procedures. Und dazu hab ich auch gleich zwei Fragen:

In Java is ja das Interface PreparedStatement eine Gegenmaßnahme zu SQLInjections, nur kann mir bitte einer erklären warum?
Ich mein im Code werden eingelesene Werte (z.b. aus einem Loginfeld) nicht direkt in das SQL-Statement geschrieben das an den Server geht, sondern mithilfe des ?-Platzhalters und set-Methoden. Aber was macht das für einen Unterschied?

Außerdem wird bei den Vorteilen von Stored Procedures auch meist Sicherheit genannt. Aber warum sind sie sicher?

Ich hoff es kann mir wer helfen.

tia,
tinker

deftenski

mit barockfelgen

Registered: May 2002
Location: back home
Posts: 1241

29.04.2007 - 10:47

ad PreparedStatement: in den Settern werden die Statements überprüft und zb. Steuerzeichen escaped. Dadurch wird aus einer potentiell gefährlichen Usereingabe für einen Namen "Name;Statement2" ein harmloses "Name\;Statement2"

ica

hmm

Registered: Jul 2002
Location: Graz
Posts: 9833

29.04.2007 - 10:48

http://www.overclockers.at/include_...enbanken_174423

:rolleyes:

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 10:50

@defenski: Aha, cool, danke

Und schätzungsweise kann man das gleiche dann auch in Stored Procedures machen. Da muss man sich den Code zur Überprüfung der eingegbenen Statements halt selber schreiben. (Is damit die erwähnte Sicherheit von Stored Procedures gemeint?)

Bearbeitet von tinker am 29.04.2007, 11:00

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 10:51

Zitat von ica
http://www.overclockers.at/include_...enbanken_174423

ok, hätte kein neuer Thread werden müssen, sry :bash:

ica

hmm

Registered: Jul 2002
Location: Graz
Posts: 9833

29.04.2007 - 11:08

Zitat von tinker
(Is damit die erwähnte Sicherheit von Stored Procedures gemeint?)

da kommen auch noch andere faktoren dazu. zb. schickst du keine queries hin und her die auf deine db-struktur hinweisen würden (außer du verschlüsselst die kommunikation sowieso...). weiters kannst du zb. bei der db alles sperren außer deinen stored procedures, somit kann nix anderes als das von dir gewünschte aus der db geholt werden.

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 12:14

Zitat von ica
weiters kannst du zb. bei der db alles sperren außer deinen stored procedures, somit kann nix anderes als das von dir gewünschte aus der db geholt werden.

Tja, das ist auch so ein Punkt den ich nicht versteh. So etwas kann ich ja auch auf Applikationsebene machen. Wenn ein User bei meiner Applikation die Daten X nud Y eingibt bekommt er sowieso nur Z zurück. Und ich werd dem User bestimmt keine Möglichkeit geben selbst SQL-Statements an den Server zu schicken... Also gebb ich praktisch eh vor was der User darf und was nicht.

Was ich mir vielleicht vorstellen könnte, wo das Sinn macht is, wenn ich z.b. ne Datenbank hab und eine andere Person schreibt ne Applikation die auf meine DB zugreift. Da kann ich dann Einschränkungen machen.

deftenski

mit barockfelgen

Registered: May 2002
Location: back home
Posts: 1241

29.04.2007 - 12:23

dann stell dir das halt vor

außerdem musst du bedenken, dass nicht immer alles so läuft, wie das vom entwickler geplant war

DKCH

Administrator
...

Registered: Aug 2002
Location: #
Posts: 3340

29.04.2007 - 12:45

Zitat von tinker
Tja, das ist auch so ein Punkt den ich nicht versteh. So etwas kann ich ja auch auf Applikationsebene machen. Wenn ein User bei meiner Applikation die Daten X nud Y eingibt bekommt er sowieso nur Z zurück. Und ich werd dem User bestimmt keine Möglichkeit geben selbst SQL-Statements an den Server zu schicken... Also gebb ich praktisch eh vor was der User darf und was nicht.

Was ich mir vielleicht vorstellen könnte, wo das Sinn macht is, wenn ich z.b. ne Datenbank hab und eine andere Person schreibt ne Applikation die auf meine DB zugreift. Da kann ich dann Einschränkungen machen.

wer sagt dass man immer über deine applikation auf die db zugreifen muss? wenn der db-user keine rechte ausser denen zum SP ausführen hat, hat er auch weniger potentielle möglichkeiten zum schaß drahn.

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 13:41

Zitat von deftenski
außerdem musst du bedenken, dass nicht immer alles so läuft, wie das vom entwickler geplant war

ok, das kenn ich eigentlich selbst sehr gut

Hab aber nicht daran gedacht...

thx

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 16:16

So, hätt ne neue Frage. Und zwar gibts ein Programm namens "keytool" mit dem man Schlüsselspeicher und Zertifikatspeicher verwalten kann. Die .exe - Datei zum Ausführen befindet sich im jdk1.6.0/lib - Ordner und dort funktioniert der Befehl auch ganz normal.

Nur wenn ich den Befehl "keytool" von einem anderen Ordner aus aufrufe, erkennt Windows den Befehl nicht. Was kann ich da machen? (keytool wird von der Konsole aus aufgerufen)

deftenski

mit barockfelgen

Registered: May 2002
Location: back home
Posts: 1241

29.04.2007 - 16:21

in PATH eintragen ..

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

29.04.2007 - 16:34

Zitat von deftenski
in PATH eintragen ..

k, thx

tinker

SQUEAK

Registered: Nov 2005
Location: NÖ
Posts: 5267

01.05.2007 - 09:51

So, hätte wieder ne Frage. Und zwar versteh ich den SSL Handshake nicht. Die Sachen mit der Einigung auf Verschlüsselungsverfahren, SSL Version usw. und den Zertifikaten versteh ich ja, nur hab ich keine Ahnung wie die zu nem Session Key kommen.

Informationen im Internet sind etwas dürftig, da is einmal von Zufallszahlen auf beiden Seiten die Rede, dann nur auf einer, außerdem is die Zufallszahl mal 28-byte mal 32-byte groß.

Könnt mir wer den SSL Handshake erklären der Ahnung davon hat!? tia

Bearbeitet von tinker am 01.05.2007, 09:59

ica

hmm

Registered: Jul 2002
Location: Graz
Posts: 9833

01.05.2007 - 11:42

also ich kenn den ssl handshake zwar nicht - aber die erklärungen klingen doch sehr logisch.

http://www.defense.at/archive/296/thread.html
http://support.microsoft.com/kb/257591

tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 10:26 Hallo zusammen! Ich arbeite gerade an ner FBA zum Thema "DB-Sicherheit und Java". Also wie man DB-Zugriffe sicherer machen kann. Zum einen beschäftige ich mit JSSE (also allgemeine Übertragungssicherheit) und DB-bezogen noch mit SQLInjections und Stored Procedures. Und dazu hab ich auch gleich zwei Fragen: In Java is ja das Interface PreparedStatement eine Gegenmaßnahme zu SQLInjections, nur kann mir bitte einer erklären warum? Ich mein im Code werden eingelesene Werte (z.b. aus einem Loginfeld) nicht direkt in das SQL-Statement geschrieben das an den Server geht, sondern mithilfe des ?-Platzhalters und set-Methoden. Aber was macht das für einen Unterschied? Außerdem wird bei den Vorteilen von Stored Procedures auch meist Sicherheit genannt. Aber warum sind sie sicher? Ich hoff es kann mir wer helfen. tia, tinker
deftenski mit barockfelgen Registered: May 2002 Location: back home Posts: 1241	29.04.2007 - 10:47 ad PreparedStatement: in den Settern werden die Statements überprüft und zb. Steuerzeichen escaped. Dadurch wird aus einer potentiell gefährlichen Usereingabe für einen Namen "Name;Statement2" ein harmloses "Name\;Statement2"
ica hmm Registered: Jul 2002 Location: Graz Posts: 9833	29.04.2007 - 10:48 http://www.overclockers.at/include_...enbanken_174423
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 10:50 @defenski: Aha, cool, danke Und schätzungsweise kann man das gleiche dann auch in Stored Procedures machen. Da muss man sich den Code zur Überprüfung der eingegbenen Statements halt selber schreiben. (Is damit die erwähnte Sicherheit von Stored Procedures gemeint?) Bearbeitet von tinker am 29.04.2007, 11:00
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 10:51 Zitat von ica http://www.overclockers.at/include_...enbanken_174423 ok, hätte kein neuer Thread werden müssen, sry
ica hmm Registered: Jul 2002 Location: Graz Posts: 9833	29.04.2007 - 11:08 Zitat von tinker (Is damit die erwähnte Sicherheit von Stored Procedures gemeint?) da kommen auch noch andere faktoren dazu. zb. schickst du keine queries hin und her die auf deine db-struktur hinweisen würden (außer du verschlüsselst die kommunikation sowieso...). weiters kannst du zb. bei der db alles sperren außer deinen stored procedures, somit kann nix anderes als das von dir gewünschte aus der db geholt werden.
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 12:14 Zitat von ica weiters kannst du zb. bei der db alles sperren außer deinen stored procedures, somit kann nix anderes als das von dir gewünschte aus der db geholt werden. Tja, das ist auch so ein Punkt den ich nicht versteh. So etwas kann ich ja auch auf Applikationsebene machen. Wenn ein User bei meiner Applikation die Daten X nud Y eingibt bekommt er sowieso nur Z zurück. Und ich werd dem User bestimmt keine Möglichkeit geben selbst SQL-Statements an den Server zu schicken... Also gebb ich praktisch eh vor was der User darf und was nicht. Was ich mir vielleicht vorstellen könnte, wo das Sinn macht is, wenn ich z.b. ne Datenbank hab und eine andere Person schreibt ne Applikation die auf meine DB zugreift. Da kann ich dann Einschränkungen machen.
deftenski mit barockfelgen Registered: May 2002 Location: back home Posts: 1241	29.04.2007 - 12:23 dann stell dir das halt vor außerdem musst du bedenken, dass nicht immer alles so läuft, wie das vom entwickler geplant war
DKCH Administrator ... Registered: Aug 2002 Location: # Posts: 3340	29.04.2007 - 12:45 Zitat von tinker Tja, das ist auch so ein Punkt den ich nicht versteh. So etwas kann ich ja auch auf Applikationsebene machen. Wenn ein User bei meiner Applikation die Daten X nud Y eingibt bekommt er sowieso nur Z zurück. Und ich werd dem User bestimmt keine Möglichkeit geben selbst SQL-Statements an den Server zu schicken... Also gebb ich praktisch eh vor was der User darf und was nicht. Was ich mir vielleicht vorstellen könnte, wo das Sinn macht is, wenn ich z.b. ne Datenbank hab und eine andere Person schreibt ne Applikation die auf meine DB zugreift. Da kann ich dann Einschränkungen machen. wer sagt dass man immer über deine applikation auf die db zugreifen muss? wenn der db-user keine rechte ausser denen zum SP ausführen hat, hat er auch weniger potentielle möglichkeiten zum schaß drahn.
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 13:41 Zitat von deftenski außerdem musst du bedenken, dass nicht immer alles so läuft, wie das vom entwickler geplant war ok, das kenn ich eigentlich selbst sehr gut Hab aber nicht daran gedacht... thx
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 16:16 So, hätt ne neue Frage. Und zwar gibts ein Programm namens "keytool" mit dem man Schlüsselspeicher und Zertifikatspeicher verwalten kann. Die .exe - Datei zum Ausführen befindet sich im jdk1.6.0/lib - Ordner und dort funktioniert der Befehl auch ganz normal. Nur wenn ich den Befehl "keytool" von einem anderen Ordner aus aufrufe, erkennt Windows den Befehl nicht. Was kann ich da machen? (keytool wird von der Konsole aus aufgerufen)
deftenski mit barockfelgen Registered: May 2002 Location: back home Posts: 1241	29.04.2007 - 16:21 in PATH eintragen ..
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	29.04.2007 - 16:34 Zitat von deftenski in PATH eintragen .. k, thx
tinker SQUEAK Registered: Nov 2005 Location: NÖ Posts: 5267	01.05.2007 - 09:51 So, hätte wieder ne Frage. Und zwar versteh ich den SSL Handshake nicht. Die Sachen mit der Einigung auf Verschlüsselungsverfahren, SSL Version usw. und den Zertifikaten versteh ich ja, nur hab ich keine Ahnung wie die zu nem Session Key kommen. Informationen im Internet sind etwas dürftig, da is einmal von Zufallszahlen auf beiden Seiten die Rede, dann nur auf einer, außerdem is die Zufallszahl mal 28-byte mal 32-byte groß. Könnt mir wer den SSL Handshake erklären der Ahnung davon hat!? tia Bearbeitet von tinker am 01.05.2007, 09:59
ica hmm Registered: Jul 2002 Location: Graz Posts: 9833	01.05.2007 - 11:42 also ich kenn den ssl handshake zwar nicht - aber die erklärungen klingen doch sehr logisch. http://www.defense.at/archive/296/thread.html http://support.microsoft.com/kb/257591

DB-Sicherheit und Java

Forum Index > Software > Coding Stuff

tinker

deftenski

ica

tinker

tinker

ica

tinker

deftenski

DKCH

tinker

tinker

deftenski

tinker

tinker

ica