DOS potenzial in django.contrib.auth ?!?

[jens]

(EDIT: abgetrennt von: "django-secure-js-login" -> http://www.python-forum.de/viewtopic.php?f=9&t=36227 )

Hm!

Mit ist heute morgen eine mögliche DOS Attacke gegen Django "auth" aufgefallen. Hab mal eine Mail an security@djangoproject.com geschickt. Details, per PN bzw. wenn sie reagiert haben...

[jens]

Ist alles nicht so schlimm:

Mir ist aufgefallen das auth.form.AuthenticationForm() kein "max_length" beim password hat. Somit die die Länge nur durch den Server limitiert. Apache z.B. hat die "LimitRequestBody Directive" dafür. Einen Standartwert dafür habe ich nicht gefunden, dürfte aber sehr hoch sein.

Django macht mit dem Password ein PBKDF2 + HMAC + SHA256 mit 15000 Iterationen... Nun hab ich angenommen, das ein sehr "langes" Passwort deutlich länger braucht, als ein "normales".

Dem ist aber nicht so. Es wird anscheinend nur mehr RAM verbraucht.

Dennoch Frage ich mich, warum man nicht einfach ein max_length=1024 einfügt. Das sollte immer ausreichend sein, oder?

[Sirius3]

@jens: da nur ein Hashwert gehasht wird, ist es egal, wie lang das Passwort ist. Ich weiß jetzt nicht, an welcher Stelle das max_length Auswirkungen hat. In der Datenbank wird nur ein Hashwert gespeichert, weshalb eine Längenbeschränkung da keinen Sinn macht und ein maxlength in einem HTML-Input ist nur ein freundlicher Hinweis, wobei jeder auch beliebig lange Strings in Formularen verschicken kann.
Ein LimitRequestBody ist damit die einzig sinnvolle und richtige Position um DoS-Angriffe über zu lange Passwörter zu verhindern.

[jens]

Da hast du recht.

Aber: Ist es nicht ein Prinzip, das man möglichst früh reinkommende Daten validieren sollte?
Ein Password länger als 1KB ist wohl eigentlich nie das richtige, oder?

Klar es gibt USB-Security-Token wie Yubikey, aber der Spukt ja normalerweise auch kein 1KB Passwort aus, oder?

[BlackJack]

@jens: Aber es wäre möglich. Und wenn es so etwas heute nicht gibt, vielleicht in ein oder zwei Jahren.

[jens]

Schon klar... Allerdings ist es ja kein Problem die Limitierung hoch zu setzten... Nicht so wie die 640KB Grenze

[BlackJack]

@jens: Aber warum gerade auf 1KiB limitieren? Und reicht das auch für andere Anfragen? Was ist denn im allgemeinen die Grösse für Anfragen die *Dir* jetzt auf der einen Seite sicher und auf der anderen nicht unterdimensioniert erscheint? In Zeiten von schnellem Internet und Webanwendungen die alles Mögliche an Daten zwischen Client und Server austauschen‽

[DasIch]

Dieses Problem tritt erstmal bei allen möglichen POST Requests auf. Resourcen werden dabei ja auch schon recht früh in Form von Speicher und Zeit schon beim parsen des Body gebunden, was gerade wenn der Request zum Application Server durckommt teuer wird. Deswegen muss man sich mit diesem Problem schon vorher befassen.

Es existiert also schon ein Limit auf die Größe dessen was du in dem Formular eingeben kannst und somit hast du auch eine gewisse Validierung. Wie du schon selbst von den Django Entwicklern erfahren hast gibt es bei dem Hashing selber kein Potential für einen DOS Angriff. Es gibt also keinen Grund die Größe in diesem Fall noch weiter zu limitieren. Ein Limit zu setzen nur weil du glaubst niemand bräuchte mehr entspricht doch genau dem gleichen Gedankengang wie bei der 640KB Grenze.

[jens]

OK, frühzeitig eingreifen ist besser. Schon klar... Aber auch da muß irgendein Wert als Limit herrangezogen werden. Klar es gibt kein wirkliches Limit. Von daher ist es halt schwierig. 1024 war einfach spontan herangezogen.

Aber anders als die DOS 640KB Geschichte, richtet man keine "Abhängigkeiten" darauf aus. Man kann flexibel das Limit frei ändern...

[Sirius3]

@jens: da das einzige sinnvolle Limit direkt beim Lesen der Requests am Server ist, und damit entweder der komplette Request oder alle Formular-Daten limitiert werden, kann eben irgendeine Änderung (Cookies, Session-Keys, CRSF-Token, etc.) das Limit sprengen, so dass man ständig am erhöhen des Limits ist. Sinnvollerweise redet man also gleich von MegaBytes und nicht von KiloBytes.

[jens]

Hab das Thema jetzt mal abgetrennt...


Wie geht man also in der Praxis vor? Also doch ein schön hohes Limit wählen, damit es nicht stört?

Hab http://httpd.apache.org/docs/trunk/en/m ... _tips.html gefunden. Zum Thema gibt es darin nur ganz Allgemein:

The directives LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, and LimitXMLRequestBody should be carefully configured to limit resource consumption triggered by client input.

[DasIch]

Es hängt halt sehr von deiner Anwendung ab. Wenn User bei der Anwendung Dateien hochladen können soll kann so ein Limit schon ganz beachtlich hoch werden.

Dein HTTP Server sollte aber ohnehin schon ein Limit per Default haben. Nginx hat z.B. ein Limit von 1MB, solange man es nicht höher setzt (oder ganz deaktiviert).

[jens]

Ich hab versucht die Standard-Limit von Apache heraus zu finden, aber erfolglos...

[BlackJack]

@jens: Apache hat da so etwas das nennt sich Dokumentation: https://httpd.apache.org/docs/2.2/mod/c ... equestBody

[jens]

Da war ich auch schon, hab aber Voreinstellung: LimitRequestBody 0 übersehen

Kann man sich wohl streiten ob das nun gut oder schlecht ist

EDIT: Achja und 0 == unbegrenzt