Superglobals: $_GET, $_POST, $_FILES in druge

Na kratko: Superglobals so vnaprej določena polja, ki jih PHP ob vsaki zahtevi samodejno napolni in so na voljo povsod v kodi. $_GET vsebuje parametre iz naslova, $_POST podatke obrazcev, $_FILES naložene datoteke, $_COOKIE piškotke in $_SERVER podatke o zahtevi in strežniku. PHP ta polja ustvari, preden se zažene koda vaše aplikacije. Zato ranljivosti v prav tej obdelavi, kot pri PHP2Shell, ne more prestreči nobeno preverjanje v aplikaciji.

Kaj so superglobals?

V PHP spremenljivka običajno velja samo v funkciji, v kateri je bila ustvarjena. Superglobals so izjema: na voljo so v vsakem območju veljavnosti, ne da bi jih bilo treba pridobiti z global. Priročnik PHP jih navaja devet.

Za netehnike je to mogoče opisati takole: superglobals so poštni nabiralnik aplikacije. Vse, kar obiskovalec pošlje, pristane tam, preden aplikacija to prebere. In vse v nabiralniku potencialno izvira od tujca.

Pregled superglobals

Posebej zahrbten je $_SERVER. Po priročniku PHP za vsako glavo zahteve ustvari vnos s HTTP_ na začetku, na primer HTTP_USER_AGENT. Te vrednosti nastavi odjemalec sam. Tudi SERVER_NAME lahko po priročniku vsebuje ime gostitelja, ki ga je dobavil odjemalec, in za varnostne odločitve ni zanesljiv.

Kako PHP napolni superglobals

Preden se izvede prvi znak vaše skripte, je PHP že delal. Prebere naslov, glave in vsebino zahteve, jih razčleni in rezultate odloži v polja. Ta korak urejajo številne nastavitve:

1. variables_order (privzeto EGPCS) določa, katere superglobals se sploh ustvarijo: Environment, GET, POST, Cookie, Server.
2. request_order (privzeto prazno) določa, iz česa se sestavi $_REQUEST. Če je prazno, velja variables_order. Priložene datoteke php.ini po priročniku iz varnostnih razlogov piškotke izpustijo.
3. max_input_vars (privzeto 1000) in max_input_nesting_level (privzeto 64) omejujeta število in gnezdenje vhodnih spremenljivk.
4. post_max_size (privzeto 8M) omejuje vsebino zahteve. Če je zahteva večja, ostaneta $_POST in $_FILES prazna.
5. enable_post_data_reading (privzeto vklopljeno) določa, ali PHP vsebino zahtev POST sploh samodejno obdela.

Če je enable_post_data_reading izklopljen, aplikacija surovo vsebino prebere sama prek php://input. Od PHP 8.4.0 obstaja dodatno request_parse_body(), ki podatke obrazcev in nalaganj obdela tudi za druge metode kot POST in dopušča lastne mejne vrednosti. Kako natančno poteka del z nalaganji, razlaga stran Kako PHP obdeluje nalaganje datotek.

Varno ravnanje s podatki zahtev

Načelo je preprosto: vsaka vrednost iz $_GET, $_POST, $_COOKIE, $_FILES in vnosov HTTP_ v $_SERVER je tuj vnos. Ob sprejemu se preveri, ob izpisu pa ustrezno maskira.

<?php
declare(strict_types=1);

// Pričakovano celo število: preveriti, ne slepo pretvoriti
$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');
}

// Dovoliti samo dovoljene vrednosti
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Izpis vedno maskirati
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Pogosta past so podatki o izvoru zahteve. Če pred spletnim strežnikom stoji reverse proxy, uravnoteževalnik obremenitve ali CDN, $_SERVER['REMOTE_ADDR'] vsebuje naslov tega posrednika, ne obiskovalca. Pravi naslov je takrat v glavi, kot je X-Forwarded-For, ki pa jo lahko vsak odjemalec nastavi sam. Aplikacija sme takšne glave obdelati samo, če zahteva dokazljivo prihaja od lastnega, znanega proxyja. Sicer je blokade po naslovu IP ali protokole lahko zlahka prevarati. Podobno velja za HTTPS: če se šifriranje konča na proxyju, mora aplikacija izrecno vedeti, da je bila prvotna povezava šifrirana.

Nadaljnje vzorce za preverjanje in filtriranje kaže prispevek Preverjanje in filtriranje vnosov v PHP. Za podatke seje v $_SESSION veljajo lastna pravila; opisana so na strani Seje in piškotki v PHP.

Superglobals in PHP2Shell: kaj se zgodi pred vašo kodo

Tu je povezava z aktualnim stanjem. CVE-2026-109618 opisuje, da lahko stanje Out of Memory PHP prekine, medtem ko so podatki zahteve le delno inicializirani; pri čiščenju zahteve se neveljavni podatki nato lahko obravnavajo kot veljavni. Pri CVE-2026-109619 lahko notranje stanje zahteve po sprostitvi pomnilnika ostane in ga uporabi poznejša zahteva v istem workerju.

Obe ranljivosti torej ležita v obdelavi, ki jo PHP sam opravlja okoli zahteve, ne v kodi aplikacije. Ekipa PHP tveganje pri mod_php ocenjuje kot najvišje; tam je bil exploit prikazan, še preden sploh teče koda aplikacije. Tega ne more preprečiti noben filter_var() in nobeno preverjanje v aplikaciji.

Kako PHP SOS pomaga konkretno?

• Preverimo veljavne mejne vrednosti za podatke zahtev za vsako spletno stran in jih nastavimo glede na aplikacijo.
• Namestimo posodobitev PHP, znova zaženemo vse workerje in stanje popravkov dokažemo v okviru naše storitve popravljanja PHP.
• Lasten razvoj preverimo glede tega, ali vrednosti iz superglobals nepreverjene pridejo v podatkovno zbirko, datotečni sistem ali izpis.
• Dnevnike spletnega strežnika zavarujemo od 20. 10. 2026, da je poznejša analiza še mogoča.

Pogosta vprašanja

Viri

• Priročnik PHP: superglobals
• Priročnik PHP: $_SERVER
• Priročnik PHP: direktive php.ini
• Priročnik PHP: request_parse_body