POST-Variablen auf 65000 Zeichen beschränkt

[weltvolk]

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?

[weltvolk]

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:

<?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";
  }
}
?>

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.

[combie]

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.

[weltvolk]

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.

[wahsaga]

Das Skript simuliert doch nur die Beschränkung einiger Provider von POST-Variablen auf eine bestimmte Länge.

Aha. *zusammenführ*

[combie]

POST-Variablen auf eine bestimmte Länge.

40 Zeichen ???
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 schon mal keine Lösung.

Du hast ja auch keine "kluge" Frage gestellt.

PS:
Alle meine Ansagen haben eine Praxisrelevanz.
Deine Frage nicht! (zumindest sehe ich sie nicht)

[weltvolk]

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.

[combie]

Womit wir dann wieder am Anfang wären:

1. warum setzt du das nicht einfach hoch?

Und wenn das nicht geht, dann such dir einen anderen Provider.

[weltvolk]

Genau, du hast einfach mal keine Lösung.

[combie]

Natürlich nicht!
Wo es nix gibt, kann ich auch nix hin zaubern.

[wahsaga]

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.

[combie]

Wenn suhosin.post.max_value_length sich wirklich auf die Länge einzelner Parameter (und nicht des gesamten Requests) bezieht

Unter vielen anderen damit einhergehenden Restriktionen ist auch diese real.

[pekka]

x
Wobei die Frage erlaubt sein sollte, welche Art von Applikation es erfordert, dass > 60 KB Daten in einem Textfeld bearbeitet werden müssen ...?
.

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?

[combie]

Zumal da auch Dateiuploads darunter fallen dürften?

Nein, tun sie nicht.
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.

[wahsaga]

Sagt er doch oben: Beim Bearbeiten von Dateien.

Ja, aber ...

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.