# JDBC und MS-Access Sicherheitslücken?



## X-Zakt (18. Mrz 2009)

Hallo,

ich schreibe gerade an meiner Facharbeit in Informatik und habe mir als Thema JDBC mit Access ausgesucht. Bis jetzt ist auch alles gut gelaufen und ich bin fast fertig, jedoch stoße ich bei einem Thema an meine Grenzen und das ist der Aspekt der Sicherheit.

Aufgrund meines geringen Vorwissens in PHP und SQL weiß ich, dass eine potentielle Angriffsmethode die SQL-Injection ist. Ich vermute mal, diese ist auch in Java möglich, da das Konzept der Manipulierung der SQL-Query nicht anders laufen wird als in PHP.
Ich vermute auch mal, dass es möglich ist, Java-Code über Datenbankmanipulierende Eingaben einzuschleusen (XSS?).

Damit endet aber schon mein Wissen/meine Ideen.
Ich würde mich freuen, wenn ihr mir helfen könntet, indem ihr mir ein paar Stichworte gebt, nach denen ich suchen kann. Leider führten mich meine Suchen immer nur zu News über neue Sicherheitslücken.


Vielen Dank und mit freundlichen Grüßen,
X-Zakt


----------



## maki (18. Mrz 2009)

>> Ich vermute auch mal, dass es möglich ist, Java-Code über Datenbankmanipulierende Eingaben einzuschleusen (XSS?).

Nur wenn man steinzeitlich den SQL Code manuel zusammenbaut und auch so die Werte setzt.
Wenn man prepared Statements verwendet (so wie jedes Persistenzframework, zB. Hibernate, iBatis, etc. pp.) geht das nicht mehr


----------



## X-Zakt (18. Mrz 2009)

maki hat gesagt.:


> Wenn man prepared Statements verwendet (so wie jedes Persistenzframework, zB. Hibernate, iBatis, etc. pp.) geht das nicht mehr



Das ist aber schon eher eine fortgeschrittene Methode, die ich aus Platzgründen in der Facharbeit nicht behandeln kann (Bin auf 10 Din A4 Seiten begrenzt).

Nehmen wir an, man hat keine Erfahrung mit irgendwelchen J2EE Features, sondern hätte gerade sein erstes Tutorial über JDBC abgeschlossen und hat nun eine kleine Anwendung programmiert.



> Nur wenn man steinzeitlich den SQL Code manuel zusammenbaut und auch so die Werte setzt.


 So ziemlich genau von diesem Wissensstand möchte ich ausgehen.


Aber danke schonmal für die Antwort


----------



## maki (18. Mrz 2009)

X-Zakt hat gesagt.:


> Das ist aber schon eher eine fortgeschrittene Methode, die ich aus Platzgründen in der Facharbeit nicht behandeln kann (Bin auf 10 Din A4 Seiten begrenzt).


In der Kürze liegt die Würze 



X-Zakt hat gesagt.:


> Nehmen wir an, man hat keine Erfahrung mit irgendwelchen J2EE Features


PreparedStatements sind nicht "irgendein J2EE feature" sondern fester Bestandteil der JDBC API und der empfohlene  und häufigste Weg um Datenbankabfragen an eine DB zu senden, sozusagen "normal".
Man vermeidet damit ziemlich viele Probleme, unter anderem SQL Injection, Formatierung, Maskierung (zB. Apostrophe), usw.



X-Zakt hat gesagt.:


> sondern hätte gerade sein erstes Tutorial über JDBC abgeschlossen und hat nun eine kleine Anwendung programmiert.


Ok.



X-Zakt hat gesagt.:


> So ziemlich genau von diesem Wissensstand möchte ich ausgehen.


Nun, dieser "nicht-wissensstand" (SCNR) ist eine gute Basis um mehr zu lernen, zB. über PreparedStatements, aber das liegt an dir.

Jedenfalls ist JDBC richtig angewendet nicht im geringsten anfällig für SQL Injection


----------



## X-Zakt (18. Mrz 2009)

maki hat gesagt.:


> Nun, dieser "nicht-wissensstand" (SCNR) ist eine gute Basis um mehr zu lernen, zB. über PreparedStatements, aber das liegt an dir.
> 
> Jedenfalls ist JDBC richtig angewendet nicht im geringsten anfällig für SQL Injection



Es geht ja in dem Fall nicht um mich, ich weiß schon was PreparedStatements sind und wie man sie anwenden kann 

Es geht um den Fall, dass JDBC nicht richtig angewendet/abgesichert wird, welche Lücken sich dadurch ergeben könnten und wie die Verfahren heißen, diese Lücken auszunutzen.


----------

