Uploadverzoeken aan de rand filteren: kansen en risico's

Kort gezegd: Uploadverzoeken aan de rand filteren betekent POST-verzoeken van het type multipart/form-data bij de proxy, de webserver of in de WAF weigeren als ze niet naar een bekend uploadpad gaan. Vakauteurs stellen dat voor als tijdelijke, officieuze maatregel tegen PHP2Shell. Ze kan formulieren en uploads breken en vervangt nooit de update. Ga in drie stappen te werk: loggen, uitzonderingen vastleggen, pas dan blokkeren, met een vaste einddatum.

Een voorstel uit de vakdiscussie

Zolang een server niet is gepatcht, zoeken beheerders naar alles wat het risico verlaagt. In de vakdiscussie over PHP2Shell dook daarbij een voorstel op: POST-verzoeken in het formaat multipart/form-data, dus het formaat voor bestandsuploads en sommige formulieren, nog slechts toestaan waar de applicatie ze werkelijk verwacht. Alle andere worden bij de proxy of in de Web Application Firewall geweigerd.

Belangrijk is de duiding. Het voorstel komt niet van php.net, maar van vakauteurs, en is uitdrukkelijk als tijdelijke maatregel bedoeld. php.net noemt eigen overbruggingsmaatregelen, gebundeld onder Noodmaatregelen als u nog niet kunt patchen. Het filter kan deze aanvullen, niet vervangen.

Wij beschrijven hier hoe u het gecontroleerd invoert. Details over waarom het tegen welke aanvallen zou kunnen helpen, laten wij bewust weg.

Wat het filter bereikt en waar het schaadt

De gedachte erachter is een verkleining van het aanvalsoppervlak. De meeste pagina's van een website hebben geen bestandsuploads nodig. Als nog maar enkele bekende paden zulke verzoeken accepteren, bereikt een groot deel van de mogelijke aanvalspogingen PHP helemaal niet meer.

De keerzijde is even duidelijk. Elke functie die multipart-verzoeken verstuurt en niet op de uitzonderingenlijst staat, valt uit. Dat betreft niet alleen voor de hand liggende uploadformulieren.

Daar komt een principieel probleem bij: Cloudflare, dat zelf beschermingsregels tegen PHP2Shell heeft uitgerold, waarschuwt dat regels op basis van alleen de verzoekgegevens niet volstaan. Hoe u beide niveaus samendenkt, beschrijft WAF of update: waarom u beide nodig hebt.

Stap 1: eerst loggen, dan blokkeren

Voordat u iets blokkeert, zoekt u uit welke paden multipart-verzoeken ontvangen. De standaardlogs tonen het inhoudstype niet. Voor Nginx legt u daarom tijdelijk een eigen logboek aan:

# in het http-blok
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';

# in het server-blok
# Let op: een access_log in het server-blok vervangt het geërfde logboek,
# geef het normale log hier daarom opnieuw op.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

De vermeldingen in $upload_pfad zijn voorbeelden. Begin met een lege uitzonderingenlijst, dan toont het testlogboek alle multipart-POST's. Onder Apache lukt hetzelfde met een omgevingsvariabele:

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

Laat het logboek enkele dagen lopen, bij voorkeur over een periode waarin ook redactie, sollicitanten en koppelingen actief waren.

Stap 2: uitzonderingen vastleggen en gecontroleerd blokkeren

Uit het testlogboek leidt u de paden af die uploads legitiem nodig hebben. Stem de lijst af met de verantwoordelijken: wie beheert inhoud, welke formulieren zijn er, welke diensten sturen gegevens?

1. Uitzonderingenlijst opstellen uit logboek en navraag en invoeren in $upload_pfad respectievelijk de RewriteCond-regels.
2. Het filter eerst in een testomgeving of in een rustig tijdvenster activeren.
3. Alle formulieren, uploads en bestelroutes zelf doorlopen.
4. Het foutenlogboek bewaken op geweigerde verzoeken (status 403) en de lijst zo nodig aanvullen.
5. Een einddatum vastleggen: na de PHP-update en de herstart van alle workers wordt het filter weer verwijderd.

In Nginx vult u daarvoor in het serverblok de blokkade aan:

# in het server-blok, na beoordeling van de logfase
if ($multipart_fremd) {
    return 403;
}

In Apache neemt mod_rewrite de taak over. Meerdere voorwaarden worden volgens de Apache-documentatie met EN verbonden:

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]

Gebruikt u een CDN of cloud-WAF, dan is dezelfde logica vaak als eigen regel na te bouwen. Ook daar geldt: eerst in logmodus, dan blokkeren.

De maatregel juist plaatsen

Het uploadfilter hoort in een rij met andere voorstellen die momenteel rondgaan. Sommige zijn zinvol, andere schadelijk. Een overzicht van welke adviezen vakauteurs afwijzen, bijvoorbeeld het blokkeren van alle verzoeken met sessiecookie, geeft Gevaarlijke valse tips over PHP2Shell.

Hoe PHP uploads intern verwerkt en waarom het formaat multipart/form-data daarbij een bijzondere rol speelt, legt Hoe PHP bestandsuploads verwerkt uit. Voor de meeste bedrijven is de belangrijkste stap echter niet het filter, maar een duidelijke datum voor de update.

Conclusie: een hulpmiddel voor dagen, niet voor maanden

Het uploadfilter aan de rand is een typisch voorbeeld van een noodmaatregel: het kan het aanvalsoppervlak in de overgangstijd verkleinen, maar heeft neveneffecten en geen officiële steun van php.net. Juist ingezet, met logfase, afgestemde uitzonderingenlijst, tests en vaste einddatum, is het verdedigbaar. Zonder deze stappen riskeert u verloren sollicitaties, geblokkeerde redacties en ongemerkte koppelingsfouten.

Neem de beslissing daarom bewust en leg vast wie haar wanneer heeft genomen. En houd de volgorde in gedachten: eerst komt de PHP-update met herstart van alle workers, de overbruggingsmaatregelen van php.net overbruggen de tijd tot dan, en het filter is hooguit een extra laag.

Hoe helpt PHP SOS concreet?

• Situatie beoordelen: wij bepalen of een uploadfilter in uw situatie zinvol is of dat de update sneller mogelijk is.
• Loggen en analyseren: wij richten de logfase in en leiden de uitzonderingenlijst af uit echte toegangen.
• Gecontroleerd blokkeren: wij activeren het filter, testen formulieren en bestelroutes en bewaken geweigerde verzoeken.
• Netjes terugbouwen: in het kader van WAF en virtual patching verwijderen wij het filter na de update weer.

Veelgestelde vragen

Bronnen

• php.net: beveiligingsmeldingen
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare-blog