Feltöltési kérések szűrése a peremen: esélyek és kockázatok

Röviden: A feltöltési kérések szűrése a peremen azt jelenti, hogy a multipart/form-data típusú POST-kéréseket a proxyn, a webszerveren vagy a WAF-ban elutasítják, ha nem egy ismert feltöltési útvonalra irányulnak. Szakírók ezt átmeneti, nem hivatalos intézkedésként javasolják a PHP2Shell ellen. Megtörheti az űrlapokat és a feltöltéseket, és soha nem pótolja a frissítést. Három lépésben járjon el: naplózni, kivételeket meghatározni, csak utána tiltani, rögzített lejárati dátummal.

Egy javaslat a szakmai vitából

Amíg egy szerver nincs javítva, az üzemeltetők mindent keresnek, ami csökkenti a kockázatot. A PHP2Shellről szóló szakmai vitában felbukkant egy javaslat: a multipart/form-data formátumú POST-kéréseket, vagyis a fájlfeltöltések és egyes űrlapok formátumát, csak ott engedélyezzék, ahol az alkalmazás valóban várja őket. Az összes többit a proxyn vagy a Web Application Firewallban utasítsák el.

A besorolás fontos. A javaslat nem a php.net-től, hanem szakírótól származik, és kifejezetten átmeneti intézkedésnek szánták. A php.net saját átmeneti intézkedéseket nevez meg, összegyűjtve az Azonnali intézkedések, ha még nem tud javítani oldalon. A szűrő ezeket kiegészítheti, nem pótolhatja.

Itt azt írjuk le, hogyan vezesse be ellenőrzötten. Azt, hogy mely támadások ellen miért segíthet, szándékosan elhagyjuk.

Mit ad a szűrő, és hol árt

A mögötte álló gondolat a támadási felület csökkentése. A weboldal oldalainak többsége nem igényel fájlfeltöltést. Ha csak néhány ismert útvonal fogad el ilyen kéréseket, a lehetséges támadási kísérletek nagy része el sem éri a PHP-t.

A hátoldal ugyanilyen egyértelmű. Minden funkció, amely multipart-kéréseket küld, és hiányzik a kivétellistáról, kiesik. Ez nem csak a nyilvánvaló feltöltési űrlapokat érinti.

Ehhez jön egy alapvető probléma: a Cloudflare, amely maga is bevezetett védőszabályokat a PHP2Shell ellen, arra figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. Hogyan gondolja össze a két szintet, azt a WAF vagy frissítés: miért kell mindkettő írja le.

1. lépés: előbb naplózni, aztán tiltani

Mielőtt bármit blokkolna, derítse ki, mely útvonalak kapnak egyáltalán multipart-kéréseket. A szabványos naplók nem mutatják a tartalomtípust. Az Nginxhez ezért átmenetileg hozzon létre egy saját naplót:

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

# a server-blokkban
# Figyelem: a server-blokkban lévő access_log helyettesíti az örökölt naplót,
# ezért a normál naplót itt ismét meg kell adni.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

A $upload_pfad bejegyzései példák. Kezdje üres kivétellistával, ekkor a tesztnapló az összes multipart-POST-ot megmutatja. Az Apache-ban ugyanez egy környezeti változóval megoldható:

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

Hagyja a naplót néhány napig futni, ideális esetben olyan időszakon át, amelyben a szerkesztőség, a jelentkezők és a felületek is aktívak voltak.

2. lépés: kivételek meghatározása és ellenőrzött tiltás

A tesztnaplóból vezesse le azokat az útvonalakat, amelyeknek jogosan szükségük van feltöltésekre. Egyeztesse a listát a felelősökkel: ki gondozza a tartalmakat, milyen űrlapok vannak, mely szolgáltatások küldenek adatokat?

1. Készítsen kivétellistát a naplóból és a visszakérdezésekből, és írja be a $upload_pfad illetve a RewriteCond sorokba.
2. A szűrőt előbb egy tesztkörnyezetben vagy egy nyugodt időablakban aktiválja.
3. Játssza végig maga az összes űrlapot, feltöltést és rendelési utat.
4. Figyelje a hibanaplót az elutasított kérések (403-as állapot) szempontjából, és szükség esetén egészítse ki a listát.
5. Rögzítsen lejárati dátumot: a PHP-frissítés és az összes worker újraindítása után a szűrőt ismét eltávolítják.

Az Nginxben ehhez a szerverblokkban egészítse ki a tiltást:

# a server-blokkban, a naplózási fázis kiértékelése után
if ($multipart_fremd) {
    return 403;
}

Az Apache-ban a mod_rewrite veszi át a feladatot. Több feltételt az Apache dokumentációja szerint ÉS-sel kapcsolnak össze:

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]

Ha CDN-t vagy felhő-WAF-ot használ, ugyanez a logika gyakran saját szabályként leképezhető. Ott is érvényes: először naplózó módban, utána tiltás.

Az intézkedés helyes besorolása

A feltöltési szűrő a jelenleg keringő további javaslatok sorába tartozik. Egyesek értelmesek, mások károsak. Áttekintést arról, hogy a szakírók mely tippeket utasítják el, például az összes munkamenet-cookie-t tartalmazó kérés blokkolását, a Veszélyes téves tippek a PHP2Shellről ad.

Hogyan dolgozza fel belsőleg a PHP a feltöltéseket, és miért játszik ebben különleges szerepet a multipart/form-data formátum, azt a Hogyan dolgozza fel a PHP a fájlfeltöltéseket magyarázza. A legtöbb vállalkozás számára a legfontosabb lépés mégsem a szűrő, hanem a frissítés világos időpontja.

Összegzés: napokra való eszköz, nem hónapokra

A perem feltöltési szűrője az vészintézkedés tipikus példája: az átmeneti időszakban csökkentheti a támadási felületet, de mellékhatásai vannak, és nincs mögötte a php.net hivatalos támogatása. Helyesen alkalmazva, naplózási fázissal, egyeztetett kivétellistával, tesztekkel és rögzített lejárati dátummal vállalható. Ezek a lépések nélkül elveszett jelentkezéseket, blokkolt szerkesztőségeket és csendes felülethibákat kockáztat.

Hozza meg ezért tudatosan a döntést, és rögzítse, ki mikor hozta. És tartsa szem előtt a sorrendet: először a PHP-frissítés jön az összes worker újraindításával, a php.net átmeneti intézkedései áthidalják az addig tartó időt, a szűrő pedig legfeljebb egy kiegészítő réteg.

Hogyan segít konkrétan a PHP SOS?

• A helyzet értékelése: Tisztázzuk, hogy az Ön helyzetében egyáltalán értelmes-e a feltöltési szűrő, vagy a frissítés gyorsabban megoldható-e.
• Naplózás és kiértékelés: Beállítjuk a naplózási fázist, és a kivétellistát valódi hozzáférésekből vezetjük le.
• Ellenőrzött tiltás: Aktiváljuk a szűrőt, teszteljük az űrlapokat és a rendelési utakat, és figyeljük az elutasított kéréseket.
• Tiszta visszabontás: A WAF és virtuális javítás keretében a frissítés után ismét eltávolítjuk a szűrőt.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare-blog