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

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

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.

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:

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

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

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

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.

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.

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. 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 tar vi bort filtret igen efter uppdateringen.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare-bloggen