DB-Sicherheit und Java

Seite 1 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/db-sicherheit_und_java_179599/page_1 - zur Vollversion wechseln!

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

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"

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

@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?)

Zitat von ica

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

Zitat von tinker

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

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.

dann stell dir das halt vor

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

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.

Zitat von deftenski

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

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)

in PATH eintragen ..

Zitat von deftenski

in PATH eintragen ..

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

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

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026