HTML-Eingabefelder auf Speicherüberlauf sichern

[odigo]

Hallo Leute,

ich bastle gerade an einer Webseite auf Basis von PHP und bin gerade bei Thema Sicherheit angelangt. Dabei ist mir eingefallen, was denn zum Beispiel passieren würde, wenn man in ein ordinäres HTML-Eingabefeld in einem Formular gigantische Mengen an Daten pasten würde. Gibt es da irgendwelche Schutzmechanismen von PHP bzw. vom Apache-Webserver? Wenn nicht, wäre es doch theoretisch möglich einen ganzen Webserver lahmzulegen, was ich mir aber nicht vorstellen kann, daß das geht. Weiß darüber jemand etwas näheres? Google wollte mir nichts dazu sagen, vielleicht hab ich auch falsch gesucht.

Gruß
odigo

 

[Cyberm@ster]

Ob es gehen würde oder nicht, kann ich dir nicht sagen, aber ich denke das müssten dann schon gigantische Datenmengen sein. Auf jedenfall kanns du dem Problem bereits auf HTML-Ebene aus dem Weg gehen indem du das maxlength-Attribut benutzt.

 

[Mackz]

Original von Cyberm@ster
indem du das maxlength-Attribut benutzt.

maxlength bietet 0 Sicherheit da man das einfach umgehen kann. Die Länge der Usereingaben sollte im Script vor dem Verarbeiten geprüft werden.

 

[odigo]

Original von Mackz
maxlength bietet 0 Sicherheit da man das einfach umgehen kann. Die Länge der Usereingaben sollte im Script vor dem Verarbeiten geprüft werden.

Aber zu diesem Zeitpunkt ist es doch schon zu spät. Da sind die Daten ja quasi schon auf dem Webserver und benötigen theoretisch auch dementsprechend viel Speicher.

 

[Cyberm@ster]

da man das einfach umgehen kann

Das wusste ich nicht, sorry. Wie geht das denn, wenn ich fragen darf?

 

[valenterry]

Original von Cyberm@ster

da man das einfach umgehen kann

Das wusste ich nicht, sorry. Wie geht das denn, wenn ich fragen darf?

Ganz einfach... ich kopier mir den Quelltext, änder des Attribut und ruf den Quelltext im Browser auf (den Veränderten auf meiner Platte) und schicke die Daten dann an den Server. Alles was clientseitig passiert ist vollkommen unsicher.

 

[Cyberm@ster]

Ach ja stimmt ... Danke.

 

[Eydeet]

Zumindest der Apache schützt das System vor einem out of memory error, indem er die Verarbeitung abbricht, sobald ein bestimmter Speicherbedarf überschritten wird. Wie hoch der sein darf, lässt sich in der php.ini einstellen (memory_limit). Was passiert, wenn memory_limit zu hoch eingestellt ist, weiß ich leider nicht

Vielleicht bricht der Apache auch einfach irgendwann die Verbindung ab, wenn der User hunderte von Megabytes auf den Server schaufelt, das dauert ja auch je nach Verbindung seine Zeit.

 

[boehmi]

Original von odigo

Original von Mackz
maxlength bietet 0 Sicherheit da man das einfach umgehen kann. Die Länge der Usereingaben sollte im Script vor dem Verarbeiten geprüft werden.

Aber zu diesem Zeitpunkt ist es doch schon zu spät. Da sind die Daten ja quasi schon auf dem Webserver und benötigen theoretisch auch dementsprechend viel Speicher.

Nicht mit einem JavaScript

 

[valenterry]

Original von boehmi

Original von odigo

Original von Mackz
maxlength bietet 0 Sicherheit da man das einfach umgehen kann. Die Länge der Usereingaben sollte im Script vor dem Verarbeiten geprüft werden.

Aber zu diesem Zeitpunkt ist es doch schon zu spät. Da sind die Daten ja quasi schon auf dem Webserver und benötigen theoretisch auch dementsprechend viel Speicher.

Nicht mit einem JavaScript

...welches dir rein gar nichts bringt.

 

[Elderan]

Hallo,

Original von Eydeet
Zumindest der Apache schützt das System vor einem out of memory error, indem er die Verarbeitung abbricht, sobald ein bestimmter Speicherbedarf überschritten wird. Wie hoch der sein darf, lässt sich in der php.ini einstellen (memory_limit).

Dies ist kein Schutz von Apache sondern von PHP, das nur am Rande.
Außerdem dient diese Funktion nicht als Schutz gegen Angriffe von außen, sondern vor schlampiger Programmierung.
Man möchte so einfach verhindern, dass ein schlecht programmierter Script den ganzen RAM auffrisst.

Es gibt aber in PHP noch die Einstellungn 'post_max_size'. Sollte selbsterklärend sein.

Ganz einfach... ich kopier mir den Quelltext, änder des Attribut und ruf den Quelltext im Browser auf

Wenn man wirklich solch eine Attacke ausführen möchte, macht es deutlich mehr Sinn, gleich einen entsprechenden HTTP Header zu senden

POST /index.php HTTP/1.1
Host: target.de
Content-Type: application/x-www-form-urlencoded
Content-Length: 1000000000 

buffer=oooooooooooooooooooo[....]verflow

Denn das Problem am Browser ist wohl, dass dieser vorher aufgibt bevor man eine kritische Datenmenge erreicht hat.
Außerdem muss man bedenken, dass der User diesen großen Header auch noch komplett hochladen muss, was lange dauern kann.

Sowie gibts bei Apache folgende Einstellung:

LimitRequestFieldSize-Direktive
Beschreibung: Begrenzt die Länge des vom Client gesendeten HTTP-Request-Headers
Syntax: LimitRequestFieldsize Bytes
Voreinstellung: LimitRequestFieldsize 8190
Kontext: Serverkonfiguration
Status: Core
Modul: core

Die Direktive gibt die Anzahl der Bytes an, die in einem HTTP-Header erlaubt sind.

Die Direktive LimitRequestFieldsize erlaubt es dem Serveradministrator, die maximale Größe eines HTTP-Request-Headers zu verringern oder erhöhen. Für den Server muss der Wert groß genug sein, um eine beliebige Headerzeile einer normalen Client-Anfrage vorzuhalten. Die Größe variiert stark zwischen den verschiedenen Client-Ausführungen, oft abhängig vom Ausmaß, mit dem der Anwender die genaue Content-Negotiation-Unterstützung seines Browsers konfiguriert hat. SPNEGO-Authentisierungs-Header können bis zu 12392 Bytes lang sein.

Die Direktive gibt dem Serveradministrator eine größere Kontrolle gegenüber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.
LimitRequestFieldSize

Beim IIS gibts ähnliche Einstellmöglichkeiten

 

[IsNull]

Das Post Limit liegt AFAIK standardmässig bei 8MB. (Gut, ist auch etwas vom Server abhängig.) Mit 8 MB bringt man noch keinen Server in die Knie, oder?

Gruss
IsNull

 

[Elderan]

Hallo,

Original von IsNull
Mit 8 MB bringt man noch keinen Server in die Knie, oder?l

Ne, nicht ansatzweise.