# Szuperglobálisok: $_GET, $_POST, $_FILES és társaik

> PHP szuperglobálisok elmagyarázva: mi van a $_GET, $_POST, $_FILES, $_SERVER és társaiban, hogyan tölti fel őket a PHP a kód előtt, és hogyan használja biztonságosan.

Forrás: https://phpsos.de/hu/php/superglobals/  
Á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 szuperglobálisok előre definiált tömbök, amelyeket a PHP minden kérésnél automatikusan feltölt, és amelyek a kódban mindenhol elérhetők. A `$_GET` a címben lévő paramétereket tartalmazza, a `$_POST` az űrlapadatokat, a `$_FILES` a feltöltött fájlokat, a `$_COOKIE` a cookie-kat, a `$_SERVER` pedig a kérésre és a szerverre vonatkozó adatokat. A PHP ezeket a tömböket az alkalmazáskód indulása előtt hozza létre. Ezért az éppen ebben a feldolgozásban lévő réseket, mint a PHP2Shell esetében, nem lehet az alkalmazásban végzett ellenőrzésekkel elfogni.

## Mik azok a szuperglobálisok?

A PHP-ban egy változó rendes esetben csak abban a függvényben érvényes, amelyben létrehozták. A szuperglobálisok a kivétel: minden érvényességi tartományban rendelkezésre állnak, anélkül hogy a `global` kulcsszóval kellene őket elővenni. A PHP-kézikönyv kilencet nevez meg közülük.

Nem műszaki embereknek így írható le: a szuperglobálisok az alkalmazás postaládája. Minden, amit egy látogató küld, ott landol, mielőtt az alkalmazás elolvasná. És a postaládában lévő mindent potenciálisan egy idegen küldött.

## A szuperglobálisok áttekintése

| Szuperglobális | Tartalom | Eredet |
|---|---|---|
| `$_GET` | a címben lévő paraméterek (query string) | kliens |
| `$_POST` | egy POST-kérés űrlapmezői | kliens |
| `$_FILES` | a feltöltött fájlokra vonatkozó adatok | kliens, a PHP által feldolgozva |
| `$_COOKIE` | a böngésző által elküldött cookie-k | kliens |
| `$_REQUEST` | a GET, a POST és adott esetben a cookie-k keveréke | kliens |
| `$_SERVER` | kérésfejlécek, módszer, útvonalak, szerveradatok | webszerver és kliens vegyesen |
| `$_ENV` | környezeti változók | szerver |
| `$_SESSION` | az aktuális munkamenet adatai | szerver tárolója |
| `$GLOBALS` | az összes globális változó | szkript |

Különösen alattomos a `$_SERVER`. A kézikönyv szerint a PHP minden kérésfejléchez létrehoz egy `HTTP_` kezdetű bejegyzést, például `HTTP_USER_AGENT`. Ezeket az értékeket maga a kliens állítja be. A `SERVER_NAME` is tartalmazhatja a kézikönyv szerint a kliens által szállított állomásnevet, és biztonsági döntésekhez nem megbízható.

## Hogyan tölti fel a PHP a szuperglobálisokat

Mielőtt a szkriptje első karaktere végrehajtódna, a PHP már dolgozott. Beolvassa a címet, a fejléceket és a kérés tartalmát, szétbontja őket, és az eredményeket a tömbökbe helyezi. Több beállítás szabályozza ezt a lépést:

1. A **`variables_order`** (alapérték `EGPCS`) meghatározza, mely szuperglobálisok jönnek egyáltalán létre: Environment, GET, POST, Cookie, Server.
2. A **`request_order`** (alapérték üres) azt határozza meg, miből áll össze a `$_REQUEST`. Ha üres, a `variables_order` érvényes. A szállított php.ini fájlok a kézikönyv szerint biztonsági okokból kihagyják a cookie-kat.
3. A **`max_input_vars`** (alapérték `1000`) és a **`max_input_nesting_level`** (alapérték `64`) a bemeneti változók számát és beágyazását korlátozza.
4. A **`post_max_size`** (alapérték `8M`) a kérés tartalmát korlátozza. Ha egy kérés nagyobb, a `$_POST` és a `$_FILES` üres marad.
5. Az **`enable_post_data_reading`** (alapérték be) azt szabályozza, hogy a PHP egyáltalán automatikusan kiértékeli-e a POST-kérések tartalmát.

Ha az `enable_post_data_reading` ki van kapcsolva, az alkalmazás a nyers tartalmat maga olvassa be a `php://input` útján. A PHP 8.4.0 óta emellett van egy `request_parse_body()` függvény, amely az űrlap- és feltöltési adatokat a POST-tól eltérő módszereknél is kiértékeli, és saját korlátértékeket enged meg. Hogy a feltöltési rész részletesen hogyan zajlik, azt a [Hogyan dolgozza fel a PHP a fájlfeltöltéseket](https://phpsos.de/hu/php/datei-uploads-intern/) oldal magyarázza.

## Biztonságos bánásmód a kérés adataival

Az alapelv egyszerű: a `$_GET`, `$_POST`, `$_COOKIE`, `$_FILES` minden értéke és a `$_SERVER` `HTTP_` bejegyzései idegen bemenetek. Átvételkor ellenőrizni kell őket, kimenetkor pedig megfelelően maszkolni.

```php
<?php
declare(strict_types=1);

// Egész számot várunk: ellenőrizzük, ne vakon alakítsuk át
$seite = filter_var($_GET['seite'] ?? '1', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 500],
]);
if ($seite === false) {
    http_response_code(400);
    exit('Ungültige Seitenzahl');
}

// Csak megengedett értékeket engedjünk át
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// A kimenetet mindig maszkoljuk
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');
```

Gyakori buktató a kérés eredetére vonatkozó adatok. Ha a webszerver előtt fordított proxy, terheléselosztó vagy CDN áll, a `$_SERVER['REMOTE_ADDR']` ennek a közvetítőnek a címét tartalmazza, nem a látogatóét. A valódi cím ilyenkor egy olyan fejlécben van, mint az `X-Forwarded-For`, amelyet viszont bármelyik kliens maga beállíthat. Az alkalmazás az ilyen fejléceket csak akkor értékelheti ki, ha a kérés igazolhatóan egy saját, ismert proxytól érkezik. Különben az IP-cím szerinti tiltások vagy a naplók könnyen megtéveszthetők. Hasonló érvényes a `HTTPS`-re: ha a titkosítás a proxynál ér véget, az alkalmazásnak kifejezetten tudnia kell, hogy az eredeti kapcsolat titkosított volt.

Az ellenőrzés és a szűrés további mintáit mutatja a [Bemenetek ellenőrzése és szűrése PHP-ban](https://phpsos.de/hu/blog/eingaben-validieren-php/) cikk. A `$_SESSION` munkamenet-adataira saját szabályok érvényesek; ezek a [Munkamenetek és cookie-k a PHP-ban](https://phpsos.de/hu/php/sessions-und-cookies/) oldalon találhatók.

## Szuperglobálisok és PHP2Shell: ami a kódja előtt történik

Itt van a kapcsolat az aktuális helyzettel. A [CVE-2026-109618](https://phpsos.de/hu/php2shell/cve-2026-109618/) azt írja le, hogy egy memóriahiányos (out-of-memory) állapot megszakíthatja a PHP-t, miközben a kérés adatai csak részben vannak inicializálva; a kérés feltakarításakor az érvénytelen adatokat érvényesként kezelheti a rendszer. A CVE-2026-109619 esetén egy kérés belső állapota a memória felszabadítása után is fennmaradhat, és egy későbbi kérés ugyanabban a workerben felhasználhatja.

Mindkét rés tehát abban a feldolgozásban van, amelyet maga a PHP végez a kérés körül, nem az alkalmazáskódban. A PHP-csapat a kockázatot a mod_php esetén értékeli a legmagasabbra; ott még azelőtt bemutattak egy exploitot, hogy egyáltalán alkalmazáskód futna. Semmilyen `filter_var()` és semmilyen ellenőrzés az alkalmazásban ezt nem akadályozhatja meg.

> **Azonnal cselekedjen:**
> Kötelező a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra való frissítés és az összes PHP-folyamat újraindítása. A php.net átmeneti intézkedései, például a `post_max_size` szűkebb korlátai, nem jelentenek teljes védelmet.

## Hogyan segít konkrétan a PHP SOS?

- Weboldalanként ellenőrizzük a kérés adataira érvényes korlátértékeket, és az alkalmazáshoz igazítjuk őket.
- Telepítjük a PHP-frissítést, újraindítjuk az összes workert, és a [PHP-javítási szolgáltatásunk](https://phpsos.de/hu/leistungen/php-patch-service/) keretében igazoljuk a patch-állapotot.
- Az egyedi fejlesztéseket megvizsgáljuk arra, hogy a szuperglobálisok értékei ellenőrzés nélkül jutnak-e az adatbázisba, a fájlrendszerbe vagy a kimenetre.
- A webszerver naplóit 2026. 10. 20-tól biztosítjuk, hogy a későbbi kiértékelés lehetséges maradjon.


## Gyakori kérdések

**Hány szuperglobális van a PHP-ban?**  
A PHP-kézikönyv kilencet nevez meg: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST és $_ENV. Minden érvényességi tartományban elérhetők, a függvényekben és metódusokban is.

**Megbízhatók a $_SERVER értékei?**  
Csak részben. A HTTP_ kezdetű bejegyzések a kliens kérésfejléceiből származnak. A kézikönyv például figyelmeztet, hogy a SERVER_NAME a kliens által szállított állomásnevet tükrözheti, és biztonsági döntésekhez nem megbízható.

**Miért üres időnként a $_POST, pedig egy űrlapot elküldtek?**  
A leggyakoribb ok egy post_max_size-nál nagyobb kérés. Ilyenkor a kézikönyv szerint a $_POST és a $_FILES üres marad. Az enable_post_data_reading kikapcsolt beállítása is ehhez vezet.

**Érdemes használni a $_REQUEST-et?**  
Inkább ne. A $_REQUEST különböző forrásokból származó adatokat kever, és hogy melyik forrás győz, az a request_order és a variables_order beállítástól függ. Az értékeket célzottan olvassa a $_GET vagy a $_POST tömbből.

## Források

- [PHP-kézikönyv: szuperglobálisok](https://www.php.net/manual/de/language.variables.superglobals.php)
- [PHP-kézikönyv: $_SERVER](https://www.php.net/manual/en/reserved.variables.server.php)
- [PHP-kézikönyv: php.ini direktívák](https://www.php.net/manual/de/ini.core.php)
- [PHP-kézikönyv: request_parse_body](https://www.php.net/manual/en/function.request-parse-body.php)