# Filtrera uppladdningsförfrågningar i kanten: möjligheter och risker

> Filtrera multipart/form-data i proxyn eller WAF: när den inofficiella övergångsåtgärden hjälper, vad den bryter och hur ni inför den säkert.

Källa: https://phpsos.de/sv/blog/upload-anfragen-am-rand-filtern/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Att filtrera uppladdningsförfrågningar i kanten betyder att avvisa POST-förfrågningar av typen `multipart/form-data` i proxyn, webbservern eller WAF när de inte går till en känd uppladdningssökväg. Fackförfattare föreslår det som tillfällig, inofficiell åtgärd mot PHP2Shell. Den kan bryta formulär och uppladdningar och ersätter aldrig uppdateringen. Gå fram i tre steg: logga, fastställ undantag, spärra först därefter, med ett fast slutdatum.

## Ett förslag ur fackdiskussionen

Tills en server är patchad letar driftansvariga efter allt som sänker risken. I fackdiskussionen om PHP2Shell dök då ett förslag upp: tillåta POST-förfrågningar i formatet `multipart/form-data`, alltså formatet för filuppladdningar och vissa formulär, bara där applikationen verkligen väntar sig dem. Alla andra avvisas i proxyn eller i Web Application Firewall.

Viktigt är placeringen. Förslaget kommer inte från php.net utan från fackförfattare, och det är uttryckligen tänkt som tillfällig åtgärd. php.net nämner egna övergångsåtgärder, samlade under [Akuta åtgärder när ni ännu inte kan patcha](https://phpsos.de/sv/php2shell/sofortmassnahmen-ohne-patch/). Filtret kan komplettera dessa men inte ersätta dem.

Vi beskriver här hur ni inför det kontrollerat. Detaljer om varför det kan hjälpa mot vilka angrepp utelämnar vi medvetet.

## Vad filtret ger och var det skadar

Tanken bakom är en minskning av angreppsytan. De flesta sidor på en webbplats behöver inga filuppladdningar. Om bara få, kända sökvägar tar emot sådana förfrågningar når en stor del av möjliga angreppsförsök inte PHP alls.

Baksidan är lika tydlig. Varje funktion som skickar multipart-förfrågningar och saknas på undantagslistan faller bort. Det gäller inte bara uppenbara uppladdningsformulär.

| Funktion | Använder ofta multipart/form-data | Risk vid spärr |
|---|---|---|
| Kontakt- och ansökningsformulär med bilaga | ja | Förfrågningar går förlorade |
| Mediehantering i CMS-backend | ja | Redaktionen kan inte ladda upp bilder |
| Import av produkter eller kunder | ja | Gränssnitt går sönder tyst |
| Formulär utan bilaga | ibland | beroende på formulärbyggaren |
| Gränssnitt och återrapporteringar från externa tjänster | sällan, men möjligt | Bortfallet märks sent |

Därtill kommer ett principiellt problem: Cloudflare, som själva har infört skyddsregler mot PHP2Shell, varnar för att regler utifrån enbart förfrågningsdata inte räcker. Hur ni tänker ihop de båda nivåerna beskriver [WAF eller uppdatering: varför ni behöver båda](https://phpsos.de/sv/blog/waf-oder-update/).

## Steg 1: först logga, sedan spärra

Innan ni blockerar något tar ni reda på vilka sökvägar som överhuvudtaget tar emot multipart-förfrågningar. Standardloggarna visar inte innehållstypen. För Nginx lägger ni därför tillfälligt upp en egen logg:

```nginx
# i http-blocket
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';

# i server-blocket
# Obs: ett access_log i server-blocket ersätter den ärvda loggen,
# ange därför den normala loggen här på nytt.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;
```

Posterna i `$upload_pfad` är exempel. Börja med en tom undantagslista, då visar testloggen alla multipart-POST. Under Apache går detsamma med en miljövariabel:

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

Låt loggen löpa i några dagar, helst under en period då även redaktion, sökande och gränssnitt var aktiva.

## Steg 2: fastställ undantag och spärra kontrollerat

Ur testloggen härleder ni de sökvägar som legitimt behöver uppladdningar. Stäm av listan med de ansvariga: vem underhåller innehåll, vilka formulär finns, vilka tjänster skickar data?

1. Upprätta undantagslistan utifrån loggen och rundfrågor och för in den i `$upload_pfad` respektive `RewriteCond`-raderna.
2. Aktivera filtret först i en testmiljö eller under ett lugnt tidsfönster.
3. Spela själva igenom alla formulär, uppladdningar och beställningsvägar.
4. Övervaka felloggen efter avvisade förfrågningar (status 403) och komplettera listan vid behov.
5. Fastställ ett slutdatum: efter PHP-uppdateringen och omstarten av alla workers tas filtret bort igen.

I Nginx kompletterar ni för det spärren i server-blocket:

```nginx
# i server-blocket, efter utvärdering av loggfasen
if ($multipart_fremd) {
    return 403;
}
```

I Apache tar `mod_rewrite` över uppgiften. Flera villkor kopplas enligt Apache-dokumentationen med OCH:

```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]
```

Använder ni ett CDN eller en moln-WAF går samma logik ofta att återge som en egen regel. Även där gäller: först i loggläge, sedan spärra.

> **Viktigt:**
> Filtret är ingen ersättning för PHP-uppdateringen och inget skäl att skjuta upp den. PHP2Shell är åtgärdat bara med PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekräftad backport, följt av omstart av alla PHP-processer.

## Placera åtgärden rätt

Uppladdningsfiltret hör hemma bland andra förslag som just nu cirkulerar. Vissa är rimliga, andra skadliga. En överblick över vilka tips fackförfattare avvisar, till exempel att blockera alla förfrågningar med sessionscookie, ger [Farliga felaktiga tips om PHP2Shell](https://phpsos.de/sv/blog/gefaehrliche-falschtipps/).

Hur PHP hanterar uppladdningar internt och varför formatet `multipart/form-data` har en särskild roll där förklarar [Hur PHP hanterar filuppladdningar](https://phpsos.de/sv/php/datei-uploads-intern/). För de flesta företag är dock det viktigaste steget inte filtret utan en tydlig tidpunkt för uppdateringen.

## Slutsats: ett verktyg för dagar, inte för månader

Uppladdningsfiltret i kanten är ett typiskt exempel på en nödåtgärd: det kan minska angreppsytan under övergångstiden men har biverkningar och inget officiellt stöd från php.net. Rätt använt, med loggfas, avstämd undantagslista, tester och fast slutdatum, är det försvarbart. Utan de stegen riskerar ni förlorade ansökningar, blockerade redaktioner och tysta gränssnittsfel.

Fatta därför beslutet medvetet och dokumentera vem som fattade det och när. Och ha ordningen i huvudet: först kommer PHP-uppdateringen med omstart av alla workers, php.nets övergångsåtgärder överbryggar tiden dit, och filtret är i bästa fall ett extra lager.

## Hur hjälper PHP SOS konkret?

- **Bedöma läget:** Vi klargör om ett uppladdningsfilter överhuvudtaget är meningsfullt i ert läge eller om uppdateringen går snabbare.
- **Logga och analysera:** Vi inrättar loggfasen och härleder undantagslistan ur verkliga åtkomster.
- **Spärra kontrollerat:** Vi aktiverar filtret, testar formulär och beställningsvägar och övervakar avvisade förfrågningar.
- **Bygga tillbaka rent:** Inom ramen för [WAF och virtuell patchning](https://phpsos.de/sv/leistungen/waf-virtuelles-patching/) tar vi bort filtret igen efter uppdateringen.


## Vanliga frågor

**Är filtrering av multipart-förfrågningar en officiell rekommendation från php.net?**  
Nej. php.net nämner andra övergångsåtgärder, till exempel gränser för post_max_size och avstängning av session.upload_progress. Filtreringen i kanten är ett förslag från fackbidrag och uttryckligen tänkt bara som tillfällig åtgärd.

**Vilka funktioner kan falla bort på grund av filtret?**  
Allt som skickar filer eller formulär i multipart-format och inte står på er undantagslista: kontaktformulär med bilaga, ansökningsformulär, mediehantering i CMS:et, importfunktioner, vissa gränssnitt och betalningsåterrapporteringar. Därför kommer en loggfas före spärren.

**Ersätter filtret PHP-uppdateringen?**  
Nej. Det minskar högst angreppsytan under övergångstiden. Cloudflare påpekar själva att regler utifrån enbart förfrågningsdata inte räcker. PHP2Shell är åtgärdat först med en patchad PHP-version och omstart av alla workers.

**Ska jag i stället blockera förfrågningar med PHPSESSID?**  
Nej. Det kringgående tipset avvisas uttryckligen av fackförfattare. Det lamslår inloggningar och varukorgar utan att ge ett hållbart skydd.

## Källor

- [php.net: säkerhetsmeddelanden](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-bloggen](https://blog.cloudflare.com/)