# Sicherheit bei JPMDBC



## Spoocky (18. Sep 2007)

Da jpmdbc über den Port 80 mit dem php-Skript kommuniziert, stellt sich die Frage, wie sicher oder wie anfällig ist das ganze?

Könnte man aus dem Daten, die an das Skript gesendet werde, Benutzername und ggf. Passwort herausfiltern?

Wenn es Sicherheitslücken hat, stellt sich die Frage, ob man das dann wirklich nutzen sollte!?


----------



## tuxedo (18. Sep 2007)

Benutzername und Passwort werden nur einmal im Klartext übertragen. Um da bei dir einzubrechen müsste man also den Netzwerktraffic sniffen und die erste Anfrage an die DB erwischen.
Alle weiteren Anfragen werden via Session bewerkstelligt. Okay, die könnte man auch ausnutzen, aber das Passwort hätte man dann trotzdem nicht: Nach dem schließen der JDBC-Verbindung wird die Session auf dem Server beendet und wird somit ungültig.

Viele nutzen phpMyAdmin um ihre DB zu konfigurieren oder SQL-Statements zu basteln. Und viele verwenden hier auch nur HTTP auf Port 80. Somit ist JPMDBC genau so sicher wie phpMyAdmin, sofern man HTTP nutzt.

Ausweg: Das ganze via HTTPS laufen lassen. Allerdings bin ich da noch nicht so weit. Aber vielleicht will ja jemand helfen oder bastelt einen Patch?

Eine weitere Möglichkeit: 
Eine verschlüsselung der gesamten Kommunikation zwischen Java und PHP, beispielsweise mit einem generierten, seeeehr langen XOR-Schlüssel. Das wäre am einfachsten und schnellsten zu realisieren. Und mit einem lang genugen Schlüssel wär's auch das sicherste.

- Alex

[edit]

Geht's nur um die verschlüsselung der Zugangsdaten, oder geht's auch um verschlüsselung des Resultsets?
Letzteres würde die Performance wohl ziemlich in den Keller ziehen.
Ersteres wäre wohl kein großes Hexenwerk ...


----------



## tuxedo (18. Sep 2007)

So, hab mal ein wenig mit HTTPS experimentiert.
Sieht nicht allzuschwer aus, sollte sich recht einfach einbauen lassen.

Werde zwei Optionen berücksichtigen:

a) Alle Zertifikate werden "einfach so" akzeptiert... 
Diese Option ist für den User die einfachste da kein Zertifikat "kompliziert" importiert werden muss. Allerdings ist die Sache auch nicht ganz so sicher. Schließlich könnte sich ja jemand dazwischenschalten und mit einem gefälschten Zertifikat arbeiten

b) Es werden nur Zertifikate im TrustStore akzeptiert. Das erfordert allerdings dass die notwendigen Zertifikate vorher in den TrustStore importiert werden.

Für alle die kein HTTPS nutzen können werde ich noch eine XOR Verschlüsselung für die Zugangsdaten einbauen (Verschlüsselung des Resultsets... weiß ich noch nicht ob das Sinn macht und auch noch performnt genug arbeitet. Muss ich testen). Natürlich auch per Option einschaltbar.

Somit dürfte das System dann sicher genug sein....

- Alex


----------



## tuxedo (19. Sep 2007)

So, ich hab mal HTTPS Support eingebaut. Ein neues Treiberpackage liegt auf der Projektseite zum Download.

Für die Nutzung von HTTPS siehe Anleitung und auch den angepassten Beispielcode auf https://jpmdbc.dev.java.net/ 

Bis jetzt funktioniert's nur mit Zertifikaten die in den Truststore importiert wurden. 
Die Option mit der man einfach alle Zertifikate akzeptieren kann kommt noch.
Auch ist eine XOR-Verschlüsselung der Zugangsdaten vorgesehen, für diejenigen die kein HTTPS nutzen können oder wollen.

- Alex

P.S. Ach übrigens: Ich konnte keinen Performanceunterschied zwischen HTTP und HTTPS feststellen. Geht beides gleich schnell bei der Übertragung. Wo es vielleicht länger dauern könnte ist der Verbindungsaufbau pro abgesetztes Query. Das hab ich noch nicht getestet...


----------



## tuxedo (26. Sep 2007)

Hat schon jemand HTTPS ausprobiert und kann ein wenig Feedback geben?

- Alex


----------



## tuxedo (10. Okt 2007)

Hallo? Erst wollten es alle möglichst sicher haben und jetzt meldet sich keiner bzgl. Feedback? Hmmpf. [jokingly]Undankbares Volk[/jokingly]

- Alex


----------

