# Uploadverzoeken aan de rand filteren: kansen en risico's

> multipart/form-data filteren bij de proxy of in de WAF: wanneer de officieuze overbruggingsmaatregel helpt, wat ze breekt en hoe u haar veilig invoert.

Bron: https://phpsos.de/nl/blog/upload-anfragen-am-rand-filtern/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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](https://phpsos.de/nl/php2shell/sofortmassnahmen-ohne-patch/). 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.

| Functie | Gebruikt vaak multipart/form-data | Risico bij blokkeren |
|---|---|---|
| Contact- en sollicitatieformulieren met bijlage | ja | Aanvragen gaan verloren |
| Mediabeheer in de CMS-backend | ja | Redactie kan geen afbeeldingen uploaden |
| Import van producten of klanten | ja | Koppelingen breken ongemerkt |
| Formulieren zonder bijlage | soms | afhankelijk van de formulierbouwer |
| Koppelingen en terugmeldingen van externe diensten | zelden, maar mogelijk | Uitval valt laat op |

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](https://phpsos.de/nl/blog/waf-oder-update/).

## 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:

```nginx
# 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:

```apache
# 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:

```nginx
# 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:

```apache
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.

> **Belangrijk:**
> Het filter is geen vervanging voor de PHP-update en geen reden om die uit te stellen. PHP2Shell is alleen verholpen met PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 of een bevestigde backport, gevolgd door de herstart van alle PHP-processen.

## 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](https://phpsos.de/nl/blog/gefaehrliche-falschtipps/).

Hoe PHP uploads intern verwerkt en waarom het formaat `multipart/form-data` daarbij een bijzondere rol speelt, legt [Hoe PHP bestandsuploads verwerkt](https://phpsos.de/nl/php/datei-uploads-intern/) 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](https://phpsos.de/nl/leistungen/waf-virtuelles-patching/) verwijderen wij het filter na de update weer.


## Veelgestelde vragen

**Is het filteren van multipart-verzoeken een officieel advies van php.net?**  
Nee. php.net noemt andere overbruggingsmaatregelen, zoals grenzen voor post_max_size en het uitschakelen van session.upload_progress. Het filteren aan de rand is een voorstel uit vakbijdragen en uitdrukkelijk alleen als tijdelijke maatregel bedoeld.

**Welke functies kunnen door het filter uitvallen?**  
Alles wat bestanden of formulieren in multipart-formaat verstuurt en niet op uw uitzonderingenlijst staat: contactformulieren met bijlage, sollicitatieformulieren, mediabeheer in het CMS, importfuncties, sommige koppelingen en betalingsterugmeldingen. Daarom komt vóór het blokkeren een logfase.

**Vervangt het filter de PHP-update?**  
Nee. Het verkleint hooguit het aanvalsoppervlak in de overgangstijd. Cloudflare wijst er zelf op dat regels op basis van alleen de verzoekgegevens niet volstaan. PHP2Shell is alleen verholpen met een gepatchte PHP-versie en de herstart van alle workers.

**Moet ik in plaats daarvan verzoeken met PHPSESSID blokkeren?**  
Nee. Dit rondgaande advies wordt door vakauteurs uitdrukkelijk afgewezen. Het legt aanmeldingen en winkelwagens lam zonder betrouwbare bescherming te bieden.

## Bronnen

- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [Nginx: ngx_http_map_module](https://nginx.org/en/docs/http/ngx_http_map_module.html)
- [Apache: mod_rewrite](https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html)
- [Cloudflare-blog](https://blog.cloudflare.com/)