Superglobali: $_GET, $_POST, $_FILES i ostali

Ukratko: Superglobali su unaprijed definirana polja koja PHP automatski popunjava pri svakom zahtjevu i koja su dostupna posvuda u kodu. $_GET sadrži parametre iz adrese, $_POST podatke obrasca, $_FILES učitane datoteke, $_COOKIE kolačiće, a $_SERVER podatke o zahtjevu i poslužitelju. PHP ta polja stvara prije nego što se pokrene kod Vaše aplikacije. Zato ranjivosti u upravo toj obradi, kao kod PHP2Shella, provjere u aplikaciji ne mogu presresti.

Što su superglobali?

U PHP-u varijabla normalno vrijedi samo u funkciji u kojoj je stvorena. Superglobali su iznimka: dostupni su u svakom dosegu, a da ih se ne mora dohvaćati pomoću global. PHP priručnik navodi devet takvih.

Za netehničke osobe to se može opisati ovako: superglobali su poštanski sandučić aplikacije. Sve što posjetitelj pošalje, tamo završava prije nego što aplikacija to pročita. A sve u sandučiću potencijalno potječe od stranca.

Superglobali ukratko

Osobito je podmukao $_SERVER. Prema priručniku PHP za svako zaglavlje zahtjeva stvara unos koji počinje s HTTP_, na primjer HTTP_USER_AGENT. Te vrijednosti postavlja sam klijent. I SERVER_NAME prema priručniku može sadržavati naziv hosta koji je isporučio klijent i nije pouzdan za sigurnosne odluke.

Kako PHP popunjava superglobale

Prije nego što se izvrši prvi znak Vaše skripte, PHP je već radio. Čita adresu, zaglavlja i sadržaj zahtjeva, rastavlja ih i rezultate sprema u polja. Taj korak upravlja nekoliko postavki:

1. variables_order (zadano EGPCS) određuje koji se superglobali uopće stvaraju: Environment, GET, POST, Cookie, Server.
2. request_order (zadano prazno) određuje od čega se gradi $_REQUEST. Ako je prazno, vrijedi variables_order. Isporučene php.ini datoteke prema priručniku iz sigurnosnih razloga izostavljaju kolačiće.
3. max_input_vars (zadano 1000) i max_input_nesting_level (zadano 64) ograničavaju broj i ugniježđenost ulaznih varijabli.
4. post_max_size (zadano 8M) ograničava sadržaj zahtjeva. Ako je zahtjev veći, $_POST i $_FILES ostaju prazni.
5. enable_post_data_reading (zadano uključeno) određuje hoće li PHP sadržaj POST zahtjeva uopće automatski obrađivati.

Ako je enable_post_data_reading isključen, aplikacija sirovi sadržaj sama čita putem php://input. Od PHP-a 8.4.0 postoji dodatno request_parse_body(), koji podatke obrazaca i uploada obrađuje i za metode koje nisu POST te dopušta vlastite granične vrijednosti. Kako detaljno teče dio s uploadom, objašnjava stranica Kako PHP obrađuje uploade datoteka.

Sigurno postupati s podacima zahtjeva

Načelo je jednostavno: svaka vrijednost iz $_GET, $_POST, $_COOKIE, $_FILES i HTTP_ unosa iz $_SERVER tuđ je unos. Provjerava se pri prihvaćanju, a pri ispisu odgovarajuće escapea.

<?php
declare(strict_types=1);

// Očekuje se cijeli broj: provjeriti umjesto slijepo pretvarati
$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');
}

// Dopustiti samo dopuštene vrijednosti
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Ispis uvijek escapeati
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Čest je kamen spoticanja podatak o podrijetlu zahtjeva. Ako ispred web-poslužitelja stoji reverse proxy, load balancer ili CDN, $_SERVER['REMOTE_ADDR'] sadrži adresu tog posrednika, a ne posjetitelja. Prava adresa tada stoji u zaglavlju poput X-Forwarded-For, koje ipak svaki klijent može postaviti sam. Aplikacija smije obrađivati takva zaglavlja samo ako zahtjev dokazano dolazi s vlastitog, poznatog proxyja. Inače se blokade prema IP adresi ili zapisnici lako mogu zavarati. Slično vrijedi za HTTPS: ako šifriranje završava na proxyju, aplikacija mora izričito znati da je izvorna veza bila šifrirana.

Dodatne uzorke za validaciju i filtriranje prikazuje članak Validacija i filtriranje unosa u PHP-u. Za podatke sesije u $_SESSION vrijede vlastita pravila; nalaze se na stranici Sesije i kolačići u PHP-u.

Superglobali i PHP2Shell: što se događa prije Vašeg koda

Ovdje je veza s aktualnim stanjem. CVE-2026-109618 opisuje da stanje nedostatka memorije može prekinuti PHP dok su podaci zahtjeva tek djelomično inicijalizirani; pri čišćenju zahtjeva nevaljani se podaci tada mogu tretirati kao valjani. Kod CVE-2026-109619 unutarnje stanje zahtjeva može ostati sačuvano nakon oslobađanja memorije i iskoristiti ga kasniji zahtjev u istom workeru.

Obje ranjivosti dakle leže u obradi koju PHP sam obavlja oko zahtjeva, a ne u kodu aplikacije. PHP tim rizik kod mod_php-a ocjenjuje najvišim; tamo je pokazan exploit prije nego što se uopće izvrši kod aplikacije. Nikakav filter_var() ni provjera u aplikaciji to ne mogu spriječiti.

Kako PHP SOS konkretno pomaže?

• Provjeravamo djelotvorne granične vrijednosti za podatke zahtjeva po web-stranici i postavljamo ih u skladu s aplikacijom.
• Instaliramo PHP ažuriranje, ponovno pokrećemo sve workere i dokazujemo razinu zakrpa u okviru naše PHP Patch usluge.
• Vlastiti razvoj provjeravamo dospijevaju li vrijednosti iz superglobala neprovjereno u bazu podataka, datotečni sustav ili ispis.
• Zapisnike web-poslužitelja osiguravamo od 20. 10. 2026. kako bi kasnija analiza ostala moguća.

Česta pitanja

Izvori

• PHP priručnik: Superglobali
• PHP priručnik: $_SERVER
• PHP priručnik: php.ini direktive
• PHP priručnik: request_parse_body