Upload-Anfragen am Rand filtern: Chancen und Risiken

Kurz gesagt: Upload-Anfragen am Rand zu filtern heißt, POST-Anfragen vom Typ multipart/form-data am Proxy, Webserver oder in der WAF abzulehnen, wenn sie nicht an einen bekannten Upload-Pfad gehen. Fachautoren schlagen das als vorübergehende, inoffizielle Maßnahme gegen PHP2Shell vor. Sie kann Formulare und Uploads brechen und ersetzt nie das Update. Gehen Sie in drei Schritten vor: protokollieren, Ausnahmen festlegen, erst dann sperren, mit festem Enddatum.

Ein Vorschlag aus der Fachdiskussion

Bis ein Server gepatcht ist, suchen Betreiber nach allem, was das Risiko senkt. In der Fachdiskussion zu PHP2Shell tauchte dabei ein Vorschlag auf: POST-Anfragen im Format multipart/form-data, also dem Format für Datei-Uploads und manche Formulare, nur noch dort zuzulassen, wo die Anwendung sie wirklich erwartet. Alle anderen werden am Proxy oder in der Web Application Firewall abgewiesen.

Wichtig ist die Einordnung. Der Vorschlag stammt nicht von php.net, sondern von Fachautoren, und er ist ausdrücklich als vorübergehende Maßnahme gedacht. php.net nennt eigene Übergangsmaßnahmen, gesammelt unter Sofortmaßnahmen, wenn Sie noch nicht patchen können. Der Filter kann diese ergänzen, nicht ersetzen.

Wir beschreiben hier, wie Sie ihn kontrolliert einführen. Details dazu, warum er gegen welche Angriffe helfen könnte, lassen wir bewusst weg.

Was der Filter leistet und wo er schadet

Der Gedanke dahinter ist eine Verkleinerung der Angriffsfläche. Die meisten Seiten einer Website brauchen keine Datei-Uploads. Wenn nur noch wenige, bekannte Pfade solche Anfragen annehmen, erreicht ein großer Teil möglicher Angriffsversuche PHP gar nicht mehr.

Die Kehrseite ist ebenso klar. Jede Funktion, die multipart-Anfragen sendet und auf der Ausnahmeliste fehlt, fällt aus. Das betrifft nicht nur offensichtliche Upload-Formulare.

Hinzu kommt ein grundsätzliches Problem: Cloudflare, das selbst Schutzregeln gegen PHP2Shell ausgerollt hat, warnt, dass Regeln anhand der Anfragedaten allein nicht genügen. Wie Sie die beiden Ebenen zusammendenken, beschreibt WAF oder Update: Warum Sie beides brauchen.

Schritt 1: Erst protokollieren, dann sperren

Bevor Sie etwas blockieren, finden Sie heraus, welche Pfade überhaupt multipart-Anfragen erhalten. Die Standard-Logs zeigen den Inhaltstyp nicht. Für Nginx legen Sie deshalb vorübergehend ein eigenes Protokoll an:

# im http-Block
map $uri $upload_pfad {
    default 0;
    ~^/kontakt/upload\.php$ 1;
    ~^/admin/medien/ 1;
}

map "$request_method:$upload_pfad:$content_type" $multipart_fremd {
    default 0;
    "~*^POST:0:multipart/form-data" 1;
}

log_format multipart '$time_iso8601 $remote_addr "$request" "$content_type" $status';

# im server-Block
# Achtung: Ein access_log im server-Block ersetzt das geerbte Protokoll,
# deshalb das normale Log hier erneut angeben.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

Die Einträge in $upload_pfad sind Beispiele. Starten Sie mit einer leeren Ausnahmeliste, dann zeigt das Testprotokoll alle multipart-POSTs. Unter Apache gelingt dasselbe mit einer Umgebungsvariablen:

# im VirtualHost
SetEnvIfNoCase Content-Type "^multipart/form-data" ist_multipart
CustomLog ${APACHE_LOG_DIR}/multipart-test.log combined env=ist_multipart

Lassen Sie das Protokoll einige Tage laufen, idealerweise über einen Zeitraum, in dem auch Redaktion, Bewerber und Schnittstellen aktiv waren.

Schritt 2: Ausnahmen festlegen und kontrolliert sperren

Aus dem Testprotokoll leiten Sie die Pfade ab, die Uploads legitim brauchen. Gleichen Sie die Liste mit den Verantwortlichen ab: Wer pflegt Inhalte, welche Formulare gibt es, welche Dienste senden Daten?

1. Ausnahmeliste aus Protokoll und Rückfragen erstellen und in $upload_pfad beziehungsweise den RewriteCond-Zeilen eintragen.
2. Den Filter zuerst auf einer Testumgebung oder in einem ruhigen Zeitfenster aktivieren.
3. Alle Formulare, Uploads und Bestellwege selbst durchspielen.
4. Das Fehlerprotokoll auf abgewiesene Anfragen (Status 403) überwachen und die Liste bei Bedarf ergänzen.
5. Ein Enddatum festlegen: Nach dem PHP-Update und dem Neustart aller Worker wird der Filter wieder entfernt.

In Nginx ergänzen Sie dafür im Server-Block die Sperre:

# im server-Block, nach Auswertung der Protokollphase
if ($multipart_fremd) {
    return 403;
}

In Apache übernimmt mod_rewrite die Aufgabe. Mehrere Bedingungen werden laut Apache-Dokumentation mit UND verknüpft:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/kontakt/upload\.php$
RewriteCond %{REQUEST_URI} !^/admin/medien/
RewriteRule ^ - [F]

Nutzen Sie ein CDN oder eine Cloud-WAF, lässt sich dieselbe Logik oft als eigene Regel abbilden. Auch dort gilt: zuerst im Protokollmodus, dann sperren.

Die Maßnahme richtig einordnen

Der Upload-Filter gehört in eine Reihe mit anderen Vorschlägen, die derzeit kursieren. Manche sind sinnvoll, andere schädlich. Einen Überblick, welche Tipps Fachautoren ablehnen, etwa das Blockieren aller Anfragen mit Session-Cookie, gibt Gefährliche Falschtipps zu PHP2Shell.

Wie PHP Uploads intern verarbeitet und warum das Format multipart/form-data dabei eine besondere Rolle spielt, erklärt Wie PHP Datei-Uploads verarbeitet. Für die meisten Unternehmen ist der wichtigste Schritt aber nicht der Filter, sondern ein klarer Termin für das Update.

Fazit: Ein Werkzeug für Tage, nicht für Monate

Der Upload-Filter am Rand ist ein typisches Beispiel für eine Notfallmaßnahme: Er kann die Angriffsfläche in der Übergangszeit verkleinern, hat aber Nebenwirkungen und keinen offiziellen Rückhalt von php.net. Richtig eingesetzt, mit Protokollphase, abgestimmter Ausnahmeliste, Tests und festem Enddatum, ist er vertretbar. Ohne diese Schritte riskieren Sie verlorene Bewerbungen, blockierte Redaktionen und stille Schnittstellenfehler.

Treffen Sie die Entscheidung deshalb bewusst und halten Sie fest, wer sie wann getroffen hat. Und behalten Sie die Reihenfolge im Kopf: Zuerst kommt das PHP-Update mit Neustart aller Worker, die Übergangsmaßnahmen von php.net überbrücken die Zeit bis dahin, und der Filter ist allenfalls eine zusätzliche Schicht.

Wie hilft PHP SOS konkret?

• Lage bewerten: Wir klären, ob ein Upload-Filter in Ihrer Situation überhaupt sinnvoll ist oder ob das Update schneller möglich ist.
• Protokollieren und auswerten: Wir richten die Protokollphase ein und leiten die Ausnahmeliste aus echten Zugriffen ab.
• Kontrolliert sperren: Wir aktivieren den Filter, testen Formulare und Bestellwege und überwachen abgewiesene Anfragen.
• Sauber zurückbauen: Im Rahmen von WAF und virtuelles Patching entfernen wir den Filter nach dem Update wieder.

Häufige Fragen

Quellen

• php.net: Sicherheitsmeldungen
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare-Blog