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

> A multipart/form-data szűrése a proxyn vagy a WAF-ban: mikor segít a nem hivatalos átmeneti intézkedés, mit tör meg, és hogyan vezesse be biztonságosan.

Forrás: https://phpsos.de/hu/blog/upload-anfragen-am-rand-filtern/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) 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.

| Funkció | Gyakran használ multipart/form-data-t | Kockázat tiltáskor |
|---|---|---|
| Kapcsolatfelvételi és jelentkezési űrlapok melléklettel | igen | a megkeresések elvesznek |
| Médiakezelés a CMS-háttérben | igen | a szerkesztőség nem tud képeket feltölteni |
| Termékek vagy ügyfelek importja | igen | a felületek csendben megtörnek |
| Melléklet nélküli űrlapok | néha | az űrlapszerkesztőtől függően |
| Külső szolgáltatások felületei és visszajelzései | ritkán, de lehetséges | a kiesés későn tűnik fel |

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ő](https://phpsos.de/hu/blog/waf-oder-update/) í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:

```nginx
# 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ó:

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

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

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

> **Fontos:**
> A szűrő nem pótolja a PHP-frissítést, és nem ok annak elhalasztására. A PHP2Shell csak a PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy egy megerősített backport révén szűnik meg, amelyet az összes PHP-folyamat újraindítása követ.

## 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](https://phpsos.de/hu/blog/gefaehrliche-falschtipps/) 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](https://phpsos.de/hu/php/datei-uploads-intern/) 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](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) keretében a frissítés után ismét eltávolítjuk a szűrőt.


## Gyakori kérdések

**A multipart-kérések szűrése a php.net hivatalos ajánlása?**  
Nem. A php.net más átmeneti intézkedéseket nevez meg, például a post_max_size határait és a session.upload_progress kikapcsolását. A perem szűrése szakmai cikkekből származó javaslat, és kifejezetten csak átmeneti intézkedésnek szánták.

**Mely funkciók eshetnek ki a szűrő miatt?**  
Minden, ami multipart formátumban küld fájlokat vagy űrlapokat, és nem szerepel a kivétellistán: mellékletes kapcsolatfelvételi űrlapok, jelentkezési űrlapok, a CMS médiakezelése, importfunkciók, egyes felületek és fizetési visszajelzések. Ezért a tiltás előtt egy naplózási fázis következik.

**A szűrő pótolja a PHP-frissítést?**  
Nem. Legfeljebb csökkenti a támadási felületet az átmeneti időszakban. A Cloudflare maga is rámutat, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A PHP2Shell csak egy javított PHP-verzióval és az összes worker újraindításával szűnik meg.

**Blokkoljam inkább a PHPSESSID-t tartalmazó kéréseket?**  
Nem. Ezt a keringő tippet szakírók kifejezetten elutasítják. Megbénítja a bejelentkezéseket és a kosarakat anélkül, hogy megbízható védelmet nyújtana.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [Nginx: ngx_http_map_module](https://nginx.org/en/docs/http/ngx_http_map_module.html)
- [Apache: mod_rewrite](https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html)
- [Cloudflare-blog](https://blog.cloudflare.com/)