unittest für SQL-Injektion...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

unittest für SQL-Injektion...

Beitragvon jens » Montag 24. März 2008, 15:14

Ich hab versucht einen Unittest für XSS und SQL-Injektion zu schreiben: http://pylucid.net:8080/pylucid/browser ... ecurity.py

Ich nutzte dazu folgenden Test Strings:

Code: Alles auswählen

SQL_INJECTIONS = (
    "DROP TABLE PyLucid_page;",
   
    "; DROP TABLE PyLucid_page;",

    '"DROP TABLE PyLucid_page;"',
    "'DROP TABLE PyLucid_page;'",

    '\"DROP TABLE PyLucid_page;\"',
    "\'DROP TABLE PyLucid_page;\'",
)


Welche Variantionen würdet ihr testen???

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Montag 24. März 2008, 18:41

Aua. Wenn du sowas Unittesten musst, hast du was falsch gemacht.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Dienstag 25. März 2008, 08:36

Der XSS und SQL-Injektion test ist auch erfolglos. Ich nutzte auch fast nur das django ORM. Dennoch finde ich so ein Test grundsätzlich nicht überflüssig.

Also jemand noch Ideen, welche Strings man noch testen sollte?

EDIT: Ich hab die liste von oben nochmal erweitert:

Code: Alles auswählen

SQL_INJECTIONS = (
    "DROP TABLE PyLucid_page;",
    "; DROP TABLE PyLucid_page;",

    '"DROP TABLE PyLucid_page;"',
    '"; DROP TABLE PyLucid_page;"',
    "'DROP TABLE PyLucid_page;'",
    "'; DROP TABLE PyLucid_page;'",

    '\"DROP TABLE PyLucid_page;\"',
    '\"; DROP TABLE PyLucid_page;\"',
    "\'DROP TABLE PyLucid_page;\'",
    "\'; DROP TABLE PyLucid_page;\'",

    # SEMICOLON
    "\x3B DROP TABLE PyLucid_page\x3B",
    u"\u003B DROP TABLE PyLucid_page\u003B",
   
    # QUOTATION MARK
    "\x22DROP TABLE PyLucid_page;\x22",
    "\x22; DROP TABLE PyLucid_page;\x22",
    u"\u0022DROP TABLE PyLucid_page;\u0022",
    u"\u0022; DROP TABLE PyLucid_page;\u0022",
   
    # APOSTROPHE
    "\x27DROP TABLE PyLucid_page;\x27",
    "\x27; DROP TABLE PyLucid_page;\x27",
    u"\u0027DROP TABLE PyLucid_page;\u0027",
    u"\u0027; DROP TABLE PyLucid_page;\u0027",
   
    # GRAVE ACCENT
    "\x60DROP TABLE PyLucid_page;\x60",
    "\x60; DROP TABLE PyLucid_page;\x60",
    u"\u0060DROP TABLE PyLucid_page;\u0060",
    u"\u0060; DROP TABLE PyLucid_page;\u0060",
)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Dienstag 25. März 2008, 11:14

jens hat geschrieben:Der XSS und SQL-Injektion test ist auch erfolglos. Ich nutzte auch fast nur das django ORM. Dennoch finde ich so ein Test grundsätzlich nicht überflüssig.

Wenn du da eine Injection hast, dann kannst du daran sowieso kaum etwas ändern, weil es ein Fehler in Django ist und nicht in PyLucid. Außer du konstruierst in PyLucid SQL selbst, aber das würde ich persönlich nicht machen (wollen).
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Dienstag 25. März 2008, 11:23

Ich vermeide es eigentlich SQL Statements selber zu erstellen. In der _install Sektion muß ich allerdings doch selber ran, um Tabellen zu löschen. Dafür habe ich noch keine Alternative, siehe: http://www.python-forum.de/topic-13685.html

Auch wenn es ein Fehler im django ORM wäre, was ist so schlimm daran es zu testen?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Beitragvon apollo13 » Dienstag 25. März 2008, 12:03

jens hat geschrieben:Auch wenn es ein Fehler im django ORM wäre, was ist so schlimm daran es zu testen?


Weil die tests in der Testsuite von django besser aufgehoben wären. Willst du jetzt für jede lib die du verwendest Tests schreiben?

Und lass dir nochmals die Antwort von mitsuhiko durch den Kopf gehen:
Aua. Wenn du sowas Unittesten musst, hast du was falsch gemacht.
BlackJack

Beitragvon BlackJack » Dienstag 25. März 2008, 12:16

Wenn man etwas nicht-triviales nicht Unittestet weil man denkt man muss das schon nicht machen, hat man eher etwas falsch gemacht.

So etwas wie "Das brauche ich nicht testen, dass kann nie passieren!", führt nicht selten zu "Huch, wie konnte denn das passieren? Das dürfte eigentlich gar nicht…". Fehler haben ja gerade die Eigenart, dass man nicht damit gerechnet hat, sonst hätte man sie ja nicht gemacht.

Berechtigter Punkt ist hier eher, dass so etwas in die Test-Suite vom ORM gehört.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Dienstag 25. März 2008, 12:51

jens hat geschrieben:Ich vermeide es eigentlich SQL Statements selber zu erstellen. In der _install Sektion muß ich allerdings doch selber ran, um Tabellen zu löschen. Dafür habe ich noch keine Alternative, siehe: http://www.python-forum.de/topic-13685.html

Die Install-Sektion ist ja nur für die Installation gedacht, also existiert sie im Produktivbetrieb ja gar nicht. Außerdem - hast du auf django-users gefragt?

jens hat geschrieben:Auch wenn es ein Fehler im django ORM wäre, was ist so schlimm daran es zu testen?

Das das in deiner Testsuite nichts verloren hat, sondern in die Django-Testsuite sollte also da wo es auch was bringt und wo jemand der so eine Testfailure hat, dann auch den Fehler beheben kann.

Du kannst auch Windows-Fehler unittesten, aber auch wenn du dort Fehler oder Regressions findest, dann hilft dir als Testsuiten-Nutzer auch kein Stück.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Dienstag 25. März 2008, 12:58

BlackJack hat geschrieben:Berechtigter Punkt ist hier eher, dass so etwas in die Test-Suite vom ORM gehört.


Wenn er dahin gehört, muss er aber vom Django-team gemacht werden (und ich hoffe doch, dassi die diese Tests machen).
Imho muss man nur das testen, was man selber Programmiert hat, niemand von uns wird unittests für open, Stringformat o.Ä schreiben.
Typischerweise will man nicht für jede genutzte Bibliothek ein audit machen.
Dementsprechend stimme ich mitsuhiko zu, wenn man das escaping Testen muss, hat man es entweder selber geschrieben (was imho eine schlechte Idee ist, da es das Rad neuerfindet) oder man eine nicht-vertrauenswürdige Bibliothek gewählt hat (was auch keine gute Idee ist).
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Dienstag 25. März 2008, 22:33

BlackJack hat geschrieben:So etwas wie "Das brauche ich nicht testen, dass kann nie passieren!", führt nicht selten zu "Huch, wie konnte denn das passieren? Das dürfte eigentlich gar nicht…". Fehler haben ja gerade die Eigenart, dass man nicht damit gerechnet hat, sonst hätte man sie ja nicht gemacht.

Es gibt gewisse Dinge die muss man mit sauberer Implementierung Lösen. So triviale Sachen wie das Absichern von SQL Statements ist sowas. Da gibts die DBAPI die Platzhalter bereitstellt, die automatisch escapen und auch noch Typen umwandeln. Wenn man die mutwillig umgeht ist das broken by design. Wenn man sie nicht umgeht braucht man da nicht auf SQL Injection unittesten.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Beitragvon veers » Mittwoch 26. März 2008, 01:05

Irgend wie wirkt das einfach nicht wie ein unittest sondern wie ein funktionaler Test. Aber zur eigentlichen Frage: Ich würde vermutlich nur ' und " als Teststrings Verwenden. Das sollte reichen um zu Testen ob escaped wird. Mehr gehört in deinen Code nicht rein. Das ist schlichtweg die Aufgabe der Escape Funktion respektive deren Testsuite. :wink:

Gruss,
Jonas
My Website - 29a.ch
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder