Üleslaadimispäringute filtreerimine serveri serval: võimalused ja riskid

Lühidalt: Üleslaadimispäringute filtreerimine serveri serval tähendab multipart/form-data tüüpi POST-päringute tagasilükkamist proxys, veebiserveris või WAF-is, kui need ei lähe tuntud üleslaadimisteele. Erialaautorid pakuvad seda ajutise, mitteametliku meetmena PHP2Shelli vastu. See võib vorme ja üleslaadimisi rikkuda ning ei asenda kunagi uuendust. Toimige kolmes sammus: logige, määrake erandid, alles siis blokeerige, kindla lõppkuupäevaga.

Ettepanek erialasest arutelust

Kuni server pole paigatud, otsivad haldajad kõike, mis riski vähendab. PHP2Shelli erialases arutelus tekkis seejuures ettepanek: lubada multipart/form-data vormingus POST-päringud, see tähendab failide üleslaadimise ja mõne vormi vorming, ainult seal, kus rakendus neid tegelikult ootab. Kõik teised lükatakse proxys või Web Application Firewallis tagasi.

Oluline on paigutus. Ettepanek ei pärine php.net'ilt, vaid erialaautoritelt ning on mõeldud otsesõnu ajutise meetmena. php.net nimetab oma üleminekumeetmeid, mis on koos lehel Kiirmeetmed, kui te ei saa veel paikama hakata. Filter võib neid täiendada, mitte asendada.

Siin kirjeldame, kuidas seda kontrollitult kasutusele võtta. Üksikasju selle kohta, miks see võiks millise rünnaku vastu aidata, jätame teadlikult välja.

Mida filter annab ja kus see kahjustab

Mõte on ründepinna vähendamine. Enamik veebisaidi lehti ei vaja failide üleslaadimist. Kui sellised päringud võtavad vastu ainult mõned tuntud teed, ei jõua suur osa võimalikest ründekatsetest PHP-ni üldse.

Varjukülg on sama selge. Iga funktsioon, mis saadab multipart-päringuid ja puudub erandite loendist, langeb välja. See ei puuduta ainult ilmseid üleslaadimisvorme.

Lisaks tuleb põhimõtteline probleem: Cloudflare, kes on ise PHP2Shelli vastu kaitsereeglid kasutusele võtnud, hoiatab, et reeglitest üksnes päringuandmete põhjal ei piisa. Kuidas need kaks tasandit koos mõelda, kirjeldab WAF või uuendus: miks vajate mõlemat.

Samm 1: esmalt logida, siis blokeerida

Enne kui midagi blokeerite, selgitage välja, millised teed üldse multipart-päringuid saavad. Tavalogid sisutüüpi ei näita. Nginxi jaoks looge seetõttu ajutiselt oma protokoll:

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

# server-plokis
# Tähelepanu: server-plokis olev access_log asendab päritud protokolli,
# seetõttu märkige tavaline logi siin uuesti.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

Kirjed $upload_pfad sees on näited. Alustage tühja erandite loendiga, siis näitab testprotokoll kõiki multipart-POST-e. Apache'is õnnestub sama keskkonnamuutujaga:

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

Laske protokollil mõni päev töötada, ideaalis ajavahemikul, mil on aktiivsed ka toimetus, kandidaadid ja liidesed.

Samm 2: erandid määrata ja kontrollitult blokeerida

Testprotokollist tuletate teed, mis üleslaadimisi legitiimselt vajavad. Võrrelge loendit vastutavate isikutega: kes hooldab sisu, millised vormid on olemas, millised teenused andmeid saadavad?

1. Koostage erandite loend protokollist ja järelepärimistest ning kandke see kirjetesse $upload_pfad või RewriteCond-ridadele.
2. Aktiveerige filter esmalt testkeskkonnas või rahulikus ajaaknas.
3. Mängige ise läbi kõik vormid, üleslaadimised ja tellimisteed.
4. Jälgige vealogi tagasilükatud päringute suhtes (olek 403) ja täiendage loendit vajaduse korral.
5. Määrake lõppkuupäev: pärast PHP uuendust ja kõigi töölisprotsesside taaskäivitamist eemaldatakse filter uuesti.

Nginxis lisate selleks server-plokki blokeeringu:

# server-plokis, pärast protokollifaasi hindamist
if ($multipart_fremd) {
    return 403;
}

Apache'is võtab ülesande üle mod_rewrite. Mitu tingimust seotakse Apache'i dokumentatsiooni järgi JA-ga:

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]

Kui kasutate CDN-i või pilve-WAF-i, saab sama loogika sageli kujutada oma reeglina. Ka seal kehtib: esmalt logimisrežiimis, siis blokeerida.

Meetme õige paigutus

Üleslaadimisfilter kuulub ritta teiste praegu levivate ettepanekutega. Mõned on mõistlikud, teised kahjulikud. Ülevaate, milliseid nõuandeid erialaautorid tagasi lükkavad, näiteks kõigi seansiküpsisega päringute blokeerimist, annab Ohtlikud valenõuanded PHP2Shelli kohta.

Kuidas PHP üleslaadimisi seespidiselt töötleb ja miks vorming multipart/form-data seejuures erilist rolli mängib, selgitab Kuidas PHP failide üleslaadimisi töötleb. Enamiku ettevõtete jaoks ei ole kõige olulisem samm aga filter, vaid selge tähtaeg uuenduseks.

Kokkuvõte: tööriist päevadeks, mitte kuudeks

Üleslaadimisfilter serveri serval on tüüpiline hädameetme näide: see võib üleminekuajal ründepinda vähendada, kuid sellel on kõrvalmõjud ja php.net'i ametlikku tuge pole. Õigesti kasutatuna, logimisfaasi, kooskõlastatud erandite loendi, testide ja kindla lõppkuupäevaga, on see põhjendatav. Ilma nende sammudeta riskite kaotatud avalduste, blokeeritud toimetuste ja vaikivate liideseviga.

Tehke otsus seetõttu teadlikult ja fikseerige, kes selle millal tegi. Ning pidage meeles järjekorda: esmalt tuleb PHP uuendus kõigi töölisprotsesside taaskäivitamisega, php.net'i üleminekumeetmed ületavad aja selleni ja filter on parimal juhul täiendav kiht.

Kuidas PHP SOS konkreetselt aitab?

• Olukorda hinnata: selgitame, kas üleslaadimisfilter on teie olukorras üldse mõistlik või on uuendus kiiremini võimalik.
• Logida ja analüüsida: seadistame logimisfaasi ja tuletame erandite loendi tegelikest pöördumistest.
• Kontrollitult blokeerida: aktiveerime filtri, testime vorme ja tellimisteid ning jälgime tagasilükatud päringuid.
• Puhtalt tagasi ehitada: WAF-i ja virtuaalse paikamise raames eemaldame filtri pärast uuendust uuesti.

Korduma kippuvad küsimused

Allikad

• php.net: turvateated
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare'i ajaveeb