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 ? Bernd -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen bernd.lentes@helmholtz-muenchen.de phone: +49 89 3187 1241 fax: +49 89 3187 2294 http://www.helmholtz-muenchen.de/idg Wir sollten nicht den Tod fürchten, sondern das schlechte Leben Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- 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
-----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
Am 26. Oktober 2012 11:39 schrieb Lentes, Bernd
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 ?
Als Programmierer kann ich dazu nur sagen: Das einfachste Mittel gegen SQL-Injection sind Prepared Statements. Wenn man das nicht macht, sondern übergebene Parameter als Strings in Queries einbaut, macht man was falsch und braucht man sowas wie GreenSQL - und die Lösung muß halt erstmal viel lernen. Sprich: Frag die Entwickler dieser Anwendung. Gruß Martin -- 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
Am 26.10.2012 11:39, schrieb Lentes, Bernd:
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.
Kurz und einfach erklärt: Du hast ein Feld "Name" und "e-Mail" in deiner Webanwendung. Per SQL speicherst du dann 'INSERT INTO user VALUES ("$name","$email");' Jetzt überlege mal, was rauskommt, wenn du bei Name statt 'Karl-Heinz' ein 'looser"); DROP TABLE user;' eingibst.
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 ?
Du kannst den Value ja so setzen, dass er das Ende des Statements bildet. Darauf zielt in der Regel auch das Abwehren von SQL-Injektions ab. Prüfe die Eingangswerte auf Plausibilität und escape Sonderzeichen und schon ist deine Anwendung relativ sicher. Gruß Uli -- 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
Hallo, Am Freitag, 26. Oktober 2012, 11:39:06 schrieb Lentes, Bernd:
wir haben eine Webanwendung mit einem Tomcat entwickelt, in die User Daten eintragen können. Ist ein wissenschaftliches Projekt.
Dann liegt die Art der Datenübergabe (SQL-Schnittstelle) in Euren eigenen Händen, wie macht Ihr das?
Um uns vor SQL Injection zu schützen,
??? Dann solltet Ihr Eure SQL-Schnittstelle hinterfragen. Sorry, aber eine Injection ist nur bei sehr schlechter Umsetzung der SQL-Schnittstelle möglich. Tipp: "parametrisiert" könnte helfen. -- Mit freundlichen Grüßen Pitt Leidner -- 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
Bernd schrieb:
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 ?
Hi, ich hab's geschafft. Ich habe in die URL mal testweise ein "update+pg_shadow+set+usecreatedb='t'+where+usename='green'" geschrieben, und GreenSQL hat das erkannt und geblockt. Das war total einfach. Immer, wenn ich mich mit Einbruchstechniken beschäftige, erschrecke ich, wie einfach diese oft sind. Muß man immer aufpassen. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- 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
participants (5)
-
Lentes, Bernd
-
Martin Schröder
-
Pitt Leidner
-
Ulrich Gehauf
-
Werner Flamme