Filtrér upload-forespørgsler i kanten: Muligheder og risici

Kort sagt: At filtrere upload-forespørgsler i kanten betyder at afvise POST-forespørgsler af typen multipart/form-data ved proxyen, webserveren eller i WAF'en, hvis de ikke går til en kendt upload-sti. Fagforfattere foreslår det som midlertidig, uofficiel foranstaltning mod PHP2Shell. Den kan ødelægge formularer og uploads og erstatter aldrig opdateringen. Gå frem i tre skridt: protokollér, fastlæg undtagelser, spær først derefter, med en fast slutdato.

Et forslag fra fagdiskussionen

Indtil en server er patchet, leder driftsansvarlige efter alt, hvad der sænker risikoen. I fagdiskussionen om PHP2Shell dukkede et forslag op: POST-forespørgsler i formatet multipart/form-data, altså formatet til filuploads og nogle formularer, kun at tillade dér, hvor applikationen virkelig forventer dem. Alle andre afvises ved proxyen eller i web application firewall'en.

Vigtig er indordningen. Forslaget stammer ikke fra php.net, men fra fagforfattere, og det er udtrykkeligt tænkt som midlertidig foranstaltning. php.net nævner egne overgangsforanstaltninger, samlet under Akutforanstaltninger, hvis I endnu ikke kan patche. Filteret kan supplere disse, ikke erstatte dem.

Vi beskriver her, hvordan I indfører det kontrolleret. Detaljer om, hvorfor det kunne hjælpe mod hvilke angreb, udelader vi bevidst.

Hvad filteret udretter, og hvor det skader

Tanken bag det er en formindskelse af angrebsfladen. De fleste sider på et website har ikke brug for filuploads. Hvis kun få, kendte stier modtager sådanne forespørgsler, når en stor del af mulige angrebsforsøg slet ikke frem til PHP.

Bagsiden er lige så tydelig. Hver funktion, der sender multipart-forespørgsler og mangler på undtagelseslisten, falder ud. Det berører ikke kun åbenlyse upload-formularer.

Hertil kommer et principielt problem: Cloudflare, som selv har udrullet beskyttelsesregler mod PHP2Shell, advarer om, at regler alene på grundlag af forespørgselsdata ikke er nok. Hvordan I tænker de to niveauer sammen, beskriver WAF eller opdatering: Hvorfor I har brug for begge dele.

Skridt 1: Først protokollér, så spær

Før I blokerer noget, finder I ud af, hvilke stier der overhovedet modtager multipart-forespørgsler. Standardlogs viser ikke indholdstypen. Til Nginx opretter I derfor midlertidigt en egen protokol:

# i http-blokken
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-blokken
# Bemærk: Et access_log i server-blokken erstatter den nedarvede protokol,
# angiv derfor det normale log påny her.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

Posterne i $upload_pfad er eksempler. Start med en tom undtagelsesliste, så viser testprotokollen alle multipart-POST'er. Under Apache lykkes det samme 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

Lad protokollen køre nogle dage, ideelt over et tidsrum, hvor også redaktion, ansøgere og grænseflader har været aktive.

Skridt 2: Fastlæg undtagelser, og spær kontrolleret

Af testprotokollen udleder I de stier, der legitimt har brug for uploads. Afstem listen med de ansvarlige: Hvem vedligeholder indhold, hvilke formularer findes der, hvilke tjenester sender data?

1. Opret undtagelseslisten ud fra protokol og rundspørge, og indfør den i $upload_pfad henholdsvis i RewriteCond-linjerne.
2. Aktivér først filteret i et testmiljø eller i et roligt tidsvindue.
3. Spil selv alle formularer, uploads og bestillingsveje igennem.
4. Hold fejlprotokollen under opsyn for afviste forespørgsler (status 403), og supplér listen efter behov.
5. Fastlæg en slutdato: Efter PHP-opdateringen og genstart af alle workers fjernes filteret igen.

I Nginx supplerer I hertil spærringen i server-blokken:

# i server-blokken, efter vurdering af protokolfasen
if ($multipart_fremd) {
    return 403;
}

I Apache overtager mod_rewrite opgaven. Flere betingelser forbindes ifølge Apache-dokumentationen med OG:

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]

Bruger I et CDN eller en cloud-WAF, kan den samme logik ofte afbildes som en egen regel. Også dér gælder: først i protokoltilstand, så spærring.

Indordn foranstaltningen rigtigt

Upload-filteret hører med i en række af andre forslag, der p.t. cirkulerer. Nogle er fornuftige, andre skadelige. Et overblik over, hvilke tip fagforfattere afviser, f.eks. blokering af alle forespørgsler med sessions-cookie, giver Farlige falske tips om PHP2Shell.

Hvordan PHP behandler uploads internt, og hvorfor formatet multipart/form-data spiller en særlig rolle dér, forklarer Sådan behandler PHP filuploads. For de fleste virksomheder er det vigtigste skridt dog ikke filteret, men en klar dato for opdateringen.

Konklusion: Et værktøj for dage, ikke for måneder

Upload-filteret i kanten er et typisk eksempel på en nødforanstaltning: Det kan formindske angrebsfladen i overgangstiden, men har bivirkninger og ingen officiel opbakning fra php.net. Rigtigt brugt, med protokolfase, afstemt undtagelsesliste, tests og fast slutdato, er det forsvarligt. Uden disse skridt risikerer I tabte ansøgninger, blokerede redaktioner og stille grænsefladefejl.

Træf derfor beslutningen bevidst, og notér, hvem der har truffet den hvornår. Og hav rækkefølgen i hovedet: Først kommer PHP-opdateringen med genstart af alle workers, php.nets overgangsforanstaltninger overbroer tiden indtil da, og filteret er højst et ekstra lag.

Hvordan hjælper PHP SOS konkret?

• Vurdér situationen: Vi afklarer, om et upload-filter overhovedet er fornuftigt i jeres situation, eller om opdateringen kan gennemføres hurtigere.
• Protokollér og analysér: Vi opsætter protokolfasen og udleder undtagelseslisten af reelle adgange.
• Spær kontrolleret: Vi aktiverer filteret, tester formularer og bestillingsveje og overvåger afviste forespørgsler.
• Byg rent tilbage: Inden for rammerne af WAF og virtuel patching fjerner vi filteret igen efter opdateringen.

Ofte stillede spørgsmål

Kilder

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