![](https://seccdn.libravatar.org/avatar/164a625f3a558d1dac0727ce6a3ba850.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lentes, Bernd [26.10.2012 11:39]:
Hi,
wir haben eine Webanwendung mit einem Tomcat entwickelt, in die User Daten eintragen können. Ist ein wissenschaftliches Projekt. Um uns vor SQL Injection zu schützen, habe ich eine GreenSQL Instanz davor, die jeden Query/Insert... erst prüft und dann ggf. weiterleitet oder verwirft. GreenSQL hat eigene Regeln um SQL Injection zu erkennen und zu verwerfen. Ich habe da als Administrator keinen Einfluß drauf, kann lediglich die SQL Injection ganz zulassen oder verwerfen. Auch an die dazugehörigen Regeln komm ich nicht ran. Ich kann aber selbst noch zusätzliche Regeln erstellen.
Jetzt würde ich das mal gerne testen, sprich eine SQL Injection versuchen. Ich habe mich mal ein bißchen hiermit beschäftigt: http://de.wikipedia.org/wiki/SQL-Injection . Hier scheint das immer so zu sein, daß an das Ende der übergeben URL ein weiteres SQL-Statement angehangen wird. Ich weiß aber doch gar, wie das eigentliche statement aussieht. Ich sehe zwar die Reihenfolge der übergebenen Werte hinter dem "?" in der URL (mittels tcpdump ermittelt). Aber ob die vom Tomcat auch in dieser Reihenfolge zu einem statement zusammengebastelt werden, kann ich nicht erkennen. Und mein zusätzliches, "böses" Statement muß doch am Ende des "guten" Statements hängen. Oder bin ich irgendwie auf dem falschen Dampfer ?
Hallo Bernd, SQL-Injection kommt z. B. zustande, indem "böse" Eingaben gemacht werden. Z. B. bei einer Passwortabfrage "xx' or '1'='1". Wenn da nicht gefiltert wird, kommt als Passwortabfrage aus "select * from usertab where pawo='$eingabe'" sowas wie "select * from usertab where pawo='xx' or '1'='1'" zusammen. Und das ist WAHR, also Prüfung bestanden... Anhand so einer Eingabe siehst Du dann die Übergabe der Daten und kannst da manipulieren. Dass die Daten immer in der URL übergeben werden, halte ich für extrem unwahrscheinlich - hast Du schon mal eine Website erlebt, die eine Passwortanfrage macht, bei der das Passwort in der URL steht, damit es jeder schön mitlesen kann? Da gibt es dann oft im Quelltext ein (oder mehrere) "hidden" Feld(er), die sich ausbeuten lassen könnten. Ebenso wie auf SQL-Injection solltest Du übrigens auf XSS (http://de.wikipedia.org/wiki/Cross-Site-Scripting) achten. Viele der SAP-Sicherheitspatches, die ich einspiele, beziehen sich darauf... Gruß Werner - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKXwUACgkQk33Krq8b42Pa5wCcCt/hO3qmLmzl8LBDLsRyB+pY B8cAmwd0z8dkcsTuUVY+FrE/B6XbCO5z =H7GH -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org