Tweet
Nach der Umstellung meines Providers auf PHP 5 liefen meine Skripte teilweise nicht mehr. Nun habe ich herausgefunden, woran das liegt: Es ist in der PHP-Konfiguration ein Sicherheitsparameter hinzugekommen, der die Länge von POST-REQUEST-Variablen auf 65000 Zeichen beschränkt, so dass z. B. im Textfeld bearbeitete Dateien, deren Zeichenanzahl über dieses Limit hinausgeht, nicht mehr gespeichert werden. Sind solche Sicherheitsmaßnahmen bei Serverbetreibern verbreitet, und wenn ja, gibt es Möglichkeiten, die betroffenen Variablen vor dem Senden zu teilen und danach wieder zusammenzusetzen?
-
-
Variable schreiben trotz Längenlimit
Im folgenden Skript wird festgelegt, dass der in einer Datei zu speichernde Inhalt eines Textfeldes nicht mehr als 40 Zeichen enthalten darf, so dass beim Überschreiten dieses Limits 0 Byte gespeichert werden:
Gibt es nun eine Möglichkeit, wenn im Textfeld zum Beispiel 150 Zeichen stehen, $textfeld in zum Beispiel 30-Byte-Schritten zu lesen und in b.txt zu schreiben, so dass $textfeld insgesamt nie das Zeichenlimit von 40 überschreitet und geleert wird? Hatte daran gedacht, mehrere Textfelder im Formular anzubieten, auf die sich eine größere Datei verteilt, aber das wäre unpraktisch.PHP Code:<?php
// wenn im Textfeld mehr als 40 Zeichen stehen, wird $textfeld geleert
$textfeld = (!empty($_POST['textfeld']) AND strlen($_POST['textfeld']) < 40) ? $_POST['textfeld'] : "";
if (!isset($_POST['speichern']) OR empty($_POST['speichern'])) {
// Textfeld-Formular
echo "<form action=\"" . $_SERVER['PHP_SELF'] . "\" method=\"post\">
<textarea name=\"textfeld\" cols=\"80\" rows=\"25\" wrap=\"off\">";
// Datei a.txt im Textfeld ausgeben
$fp = fopen("a.txt", "rb");
while (!feof($fp)) {
echo fread($fp, 8192);
}
fclose($fp);
echo "</textarea>
<input type=\"submit\" name=\"speichern\" value=\"speichern\">
</form>";
} else {
// beim Speichern wird $textfeld in b.txt geschrieben
if ($fp = fopen("b.txt", "wb") AND fwrite($fp, $textfeld) AND fclose($fp)) {
echo "Datei wurde gespeichert";
} else {
echo "Datei konnte nicht gespeichert werden";
}
}
?> -
1. warum setzt du das nicht einfach hoch?
2. PHP_SELF kann XSS Attacken erlauben
3. Fwrite() kann durchaus mal 0 liefern.
4. Was passiert wenn einer mal </textarea> in dein Feld eingibt?
Alles in allem: Sehr unsauber!! Ja, teilweise sogar gefährlich.Comment
-
Das Skript simuliert doch nur die Beschränkung einiger Provider von POST-Variablen auf eine bestimmte Länge. Du hast schon mal keine Lösung. Wahrscheinlich ist es auch hoffnungslos.
Comment
-
Aha. *zusammenführ*Originally posted by weltvolk View PostI don't believe in rebirth. Actually, I never did in my whole lives.Comment
-
40 Zeichen ???POST-Variablen auf eine bestimmte Länge.
Neee....
Die Begrenzungen liegen typischer Weise im "ettliche MB" Bereich. Ausnahme: Suhosin.
Und nein!
Es wäre ja eine fürchterlich dumme Begrenzung, wenn es da einen Umweg geben würde.
Du hast ja auch keine "kluge" Frage gestellt.Du hast schon mal keine Lösung.
PS:
Alle meine Ansagen haben eine Praxisrelevanz.
Deine Frage nicht! (zumindest sehe ich sie nicht)Last edited by combie; 10-08-2009, 17:13.Comment
-
Wie gesagt ist es mit 40 Byte nur ein Beispiel, die entsprechende Lösung soll ja für alle Variablengrößen funktionieren. Davon abgesehen ist es tatsächlich "suhosin", was die Längenbegrenzung verursacht: suhosin.post.max_value_length. Meine Frage dürfte somit Praxisrelevanz haben.Comment
-
Womit wir dann wieder am Anfang wären:
Und wenn das nicht geht, dann such dir einen anderen Provider.1. warum setzt du das nicht einfach hoch?Comment
-
Genau, du hast einfach mal keine Lösung.
Comment
-
-
Wenn suhosin.post.max_value_length sich wirklich auf die Länge einzelner Parameter (und nicht des gesamten Requests) bezieht - dann kannst du auf dem Client gerne JavaScript nutzen, um einen laaangen Textfeld-Inhalt aufzusplitten, und auf mehrere (dynamisch erstellte) Felder zu verteilen.
Wobei die Frage erlaubt sein sollte, welche Art von Applikation es erfordert, dass > 60 KB Daten in einem Textfeld bearbeitet werden müssen ...?
Zumal der ganze Krempel ja erst mal zum Client, und dann von diesem wieder zum Server geschickt werden muss. Also "performant" würde ich in den allermeisten Szenarien anders definieren.I don't believe in rebirth. Actually, I never did in my whole lives.Comment
-
Unter vielen anderen damit einhergehenden Restriktionen ist auch diese real.Wenn suhosin.post.max_value_length sich wirklich auf die Länge einzelner Parameter (und nicht des gesamten Requests) beziehtComment
-
Sagt er doch oben: Beim Bearbeiten von Dateien. Der Provider soll das hochstellen, das ist so nicht zumutbar. Zumal da auch Dateiuploads darunter fallen dürften?Originally posted by wahsaga View PostComment
-
Nein, tun sie nicht.Zumal da auch Dateiuploads darunter fallen dürften?
Auch wenn sie nicht ganz frei von Restriktionen sind.
Ich habe Suhosin seit Jahren im Einsatz.
Das Ding ist einfach Klasse auf shared Servern, wenn PHP als Modul läuft.
Es gibt keine echte Alternative.Last edited by combie; 10-08-2009, 19:22.Comment
-
Ja, aber ...Originally posted by pekka View Post
Kommt 'ne Frau zum Arzt, "Herr Doktor, Herr Doktor! Ich habe einen Knoten in der Brust!!!"
Arzt (kopfschüttelnd, nachdenklich): "Ja wer macht denn sowas ...?"
Und zum hier geschilderten Vorgehen fällt mir nur in etwa das gleiche ein, wie dem Arzt.I don't believe in rebirth. Actually, I never did in my whole lives.Comment
Comment