Superglobals: $_GET, $_POST, $_FILES și celelalte

Pe scurt: Superglobals sunt array-uri predefinite, pe care PHP le umple automat la fiecare cerere și care sunt disponibile oriunde în cod. $_GET conține parametrii din adresă, $_POST datele din formulare, $_FILES fișierele încărcate, $_COOKIE cookie-urile și $_SERVER informații despre cerere și server. PHP creează aceste array-uri înainte ca codul aplicației dumneavoastră să pornească. De aceea, vulnerabilitățile din exact această prelucrare, ca la PHP2Shell, nu pot fi interceptate prin verificări în aplicație.

Ce sunt superglobals?

În PHP, o variabilă este valabilă în mod normal doar în funcția în care a fost creată. Superglobals sunt excepția: sunt disponibile în orice domeniu de vizibilitate, fără a trebui aduse cu global. Manualul PHP menționează nouă dintre ele.

Pentru nespecialiști se poate descrie așa: superglobals sunt cutia poștală a aplicației. Tot ce trimite un vizitator ajunge acolo înainte ca aplicația să citească. Și tot ce se află în cutia poștală provine potențial de la un străin.

Superglobals pe scurt

Deosebit de capcanos este $_SERVER. Potrivit manualului, PHP creează pentru fiecare antet al cererii o intrare care începe cu HTTP_, de exemplu HTTP_USER_AGENT. Aceste valori le setează clientul însuși. Și SERVER_NAME poate conține, potrivit manualului, numele de gazdă furnizat de client și nu este de încredere pentru decizii de securitate.

Cum umple PHP superglobals

Înainte ca primul caracter al scriptului dumneavoastră să fie executat, PHP a lucrat deja. Citește adresa, antetele și conținutul cererii, le descompune și depune rezultatele în array-uri. Mai multe setări controlează acest pas:

1. variables_order (implicit EGPCS) stabilește ce superglobals sunt create deloc: Environment, GET, POST, Cookie, Server.
2. request_order (implicit gol) determină din ce se formează $_REQUEST. Dacă este gol, se aplică variables_order. Fișierele php.ini livrate omit, potrivit manualului, cookie-urile din motive de securitate.
3. max_input_vars (implicit 1000) și max_input_nesting_level (implicit 64) limitează numărul și imbricarea variabilelor de intrare.
4. post_max_size (implicit 8M) limitează conținutul cererii. Dacă o cerere este mai mare, $_POST și $_FILES rămân goale.
5. enable_post_data_reading (implicit pornit) controlează dacă PHP evaluează automat conținutul cererilor POST.

Dacă enable_post_data_reading este dezactivat, aplicația citește singură conținutul brut prin php://input. Din PHP 8.4.0 există suplimentar request_parse_body(), care evaluează datele de formular și de upload și pentru alte metode decât POST și permite valori-limită proprii. Cum decurge în detaliu partea de upload explică pagina Cum prelucrează PHP upload-urile de fișiere.

Manevrarea sigură a datelor cererii

Principiul este simplu: orice valoare din $_GET, $_POST, $_COOKIE, $_FILES și din intrările HTTP_ ale $_SERVER este o introducere străină. Ea este verificată la preluare și escapată corespunzător la ieșire.

<?php
declare(strict_types=1);

// Se așteaptă un număr întreg: verificați în loc să convertiți orbește
$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');
}

// Permiteți doar valori admise
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Escapați întotdeauna ieșirea
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

O capcană frecventă sunt informațiile despre originea unei cereri. Dacă în fața serverului web se află un reverse proxy, un load balancer sau un CDN, $_SERVER['REMOTE_ADDR'] conține adresa acestui intermediar, nu a vizitatorului. Adresa reală se află atunci într-un antet precum X-Forwarded-For, pe care însă orice client îl poate seta singur. Aplicația are voie să evalueze asemenea antete doar dacă cererea vine dovedit de la un proxy propriu, cunoscut. Altfel, blocările după adresa IP sau protocoalele pot fi ușor înșelate. Ceva asemănător se aplică lui HTTPS: dacă criptarea se încheie la proxy, aplicația trebuie să știe explicit că conexiunea inițială a fost criptată.

Alte modele de validare și filtrare arată articolul Validarea și filtrarea introducerilor în PHP. Pentru datele de sesiune din $_SESSION se aplică reguli proprii; ele se află pe pagina Sesiuni și cookie-uri în PHP.

Superglobals și PHP2Shell: ce se întâmplă înaintea codului dumneavoastră

Aici se află legătura cu situația actuală. CVE-2026-109618 descrie faptul că o stare de lipsă de memorie (out-of-memory) poate întrerupe PHP în timp ce datele cererii sunt inițializate doar parțial; la curățarea cererii, datele nevalide pot fi apoi tratate ca valide. La CVE-2026-109619, starea internă a unei cereri poate persista după eliberarea memoriei și poate fi folosită de o cerere ulterioară în același worker.

Ambele vulnerabilități se află deci în prelucrarea pe care PHP însuși o face în jurul cererii, nu în codul aplicației. Echipa PHP încadrează riscul cel mai sus la mod_php; acolo a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Niciun filter_var() și nicio verificare din aplicație nu poate împiedica asta.

Cum ajută PHP SOS concret?

• Verificăm valorile-limită efective pentru datele cererii pentru fiecare site și le setăm potrivit aplicației.
• Instalăm actualizarea PHP, reporniți toți workerii și dovedim starea patch-ului în cadrul serviciului nostru de patch PHP.
• Verificăm dezvoltările proprii dacă valori din superglobals ajung neverificate în baza de date, în sistemul de fișiere sau în ieșire.
• Păstrăm log-urile serverului web începând cu 20.10.2026, pentru ca o evaluare ulterioară să rămână posibilă.

Întrebări frecvente

Surse

• Manualul PHP: superglobals
• Manualul PHP: $_SERVER
• Manualul PHP: directivele php.ini
• Manualul PHP: request_parse_body