Filtriranje zahtev za nalaganje na robu: priložnosti in tveganja

Na kratko: Filtriranje zahtev za nalaganje na robu pomeni zavrniti zahteve POST vrste multipart/form-data na proxyju, spletnem strežniku ali v WAF, če ne gredo na znano pot za nalaganje. Strokovni avtorji to predlagajo kot začasen, neuraden ukrep proti PHP2Shell. Lahko pokvari obrazce in nalaganja ter nikoli ne nadomešča posodobitve. Postopajte v treh korakih: beležite, določite izjeme, šele nato zaprite, s stalnim datumom konca.

Predlog iz strokovne razprave

Dokler strežnik ni popravljen, upravljavci iščejo vse, kar zmanjšuje tveganje. V strokovni razpravi o PHP2Shell se je pojavil predlog: zahteve POST v obliki multipart/form-data, torej v obliki za nalaganje datotek in nekatere obrazce, dovoliti samo tam, kjer jih aplikacija res pričakuje. Vse druge se na proxyju ali v požarnem zidu spletnih aplikacij zavrnejo.

Pomembna je umestitev. Predlog ne izvira od php.net, ampak od strokovnih avtorjev, in je izrecno mišljen kot začasen ukrep. php.net navaja lastne prehodne ukrepe, zbrane pod Takojšnji ukrepi, če popravka še ne morete namestiti. Filter jih lahko dopolni, ne nadomesti.

Tu opisujemo, kako ga uvedete nadzorovano. Podrobnosti o tem, zakaj bi lahko pomagal proti katerim napadom, namerno izpuščamo.

Kaj filter prinese in kje škoduje

Ideja za njim je zmanjšanje napadalne površine. Večina strani spletnega mesta ne potrebuje nalaganja datotek. Če take zahteve sprejema samo še nekaj znanih poti, velik del možnih poskusov napada PHP sploh ne doseže več.

Slaba stran je enako jasna. Vsaka funkcija, ki pošilja zahteve multipart in je ni na seznamu izjem, odpove. To ne zadeva samo očitnih obrazcev za nalaganje.

Poleg tega obstaja načelna težava: Cloudflare, ki je sam uvedel zaščitna pravila proti PHP2Shell, opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. Kako obe ravni združite, opisuje WAF ali posodobitev: zakaj potrebujete oboje.

Korak 1: najprej beležite, nato zaprite

Preden karkoli blokirate, ugotovite, katere poti sploh prejemajo zahteve multipart. Standardni dnevniki vrste vsebine ne kažejo. Za Nginx zato začasno ustvarite lasten zapisnik:

# v bloku http
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';

# v bloku server
# Pozor: access_log v bloku server nadomesti podedovani zapisnik,
# zato tu znova navedite običajni dnevnik.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

Vnosi v $upload_pfad so primeri. Začnite s praznim seznamom izjem, nato testni zapisnik pokaže vse multipart POST. Pod Apache enako uspe z okoljsko spremenljivko:

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

Pustite zapisnik teči nekaj dni, idealno v obdobju, ko so bili aktivni tudi uredništvo, kandidati in vmesniki.

Korak 2: določite izjeme in zaprite nadzorovano

Iz testnega zapisnika izpeljite poti, ki nalaganja legitimno potrebujejo. Seznam uskladite z odgovornimi: kdo ureja vsebine, kateri obrazci obstajajo, katere storitve pošiljajo podatke?

1. Seznam izjem ustvarite iz zapisnika in poizvedb ter ga vnesite v $upload_pfad oziroma v vrstice RewriteCond.
2. Filter najprej aktivirajte v testnem okolju ali v mirnem časovnem oknu.
3. Sami preizkusite vse obrazce, nalaganja in poti naročil.
4. Spremljajte dnevnik napak za zavrnjene zahteve (status 403) in seznam po potrebi dopolnite.
5. Določite datum konca: po posodobitvi PHP in ponovnem zagonu vseh delavcev se filter spet odstrani.

V Nginx v bloku strežnika za to dodate zaporo:

# v bloku server, po ovrednotenju faze beleženja
if ($multipart_fremd) {
    return 403;
}

V Apache nalogo prevzame mod_rewrite. Po dokumentaciji Apache se več pogojev poveže z IN:

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]

Če uporabljate CDN ali oblačni WAF, je isto logiko pogosto mogoče upodobiti kot lastno pravilo. Tudi tam velja: najprej v načinu beleženja, nato zaprite.

Pravilna umestitev ukrepa

Filter nalaganj sodi v vrsto drugih predlogov, ki trenutno krožijo. Nekateri so smiselni, drugi škodljivi. Pregled, katere nasvete strokovni avtorji zavračajo, na primer blokiranje vseh zahtev s piškotkom seje, daje Nevarni napačni nasveti za PHP2Shell.

Kako PHP nalaganja obdeluje notranje in zakaj ima pri tem oblika multipart/form-data posebno vlogo, pojasnjuje Kako PHP obdeluje nalaganje datotek. Za večino podjetij pa najpomembnejši korak ni filter, ampak jasen termin za posodobitev.

Sklep: orodje za dneve, ne za mesece

Filter nalaganj na robu je tipičen primer zasilnega ukrepa: lahko zmanjša napadalno površino v prehodnem času, vendar ima stranske učinke in nima uradne podpore php.net. Pravilno uporabljen, s fazo beleženja, usklajenim seznamom izjem, preizkusi in stalnim datumom konca, je upravičen. Brez teh korakov tvegate izgubljene prijave, blokirana uredništva in tihe napake vmesnikov.

Odločitev zato sprejmite zavestno in zabeležite, kdo jo je sprejel in kdaj. In imejte v mislih vrstni red: najprej pride posodobitev PHP s ponovnim zagonom vseh delavcev, prehodni ukrepi php.net premostijo čas do tega, filter pa je kvečjemu dodatna plast.

Kako PHP SOS pomaga konkretno?

• Ocena razmer: razjasnimo, ali je filter nalaganj v vaši situaciji sploh smiseln ali je posodobitev mogoča hitreje.
• Beleženje in ovrednotenje: vzpostavimo fazo beleženja in seznam izjem izpeljemo iz pravih dostopov.
• Nadzorovana zapora: filter aktiviramo, preizkusimo obrazce in poti naročil ter spremljamo zavrnjene zahteve.
• Čist umik: v okviru WAF in virtualnega popravljanja filter po posodobitvi znova odstranimo.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Blog Cloudflare