unittest für SQL-Injektion...

[jens]

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???

[mitsuhiko]

Aua. Wenn du sowas Unittesten musst, hast du was falsch gemacht.

[jens]

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",
)

[Leonidas]

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).

[jens]

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?

[apollo13]

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]

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.

[Leonidas]

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?

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.

[keppla]

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).

[mitsuhiko]

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.

[veers]

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.

Gruss,
Jonas