# Superglobals: $_GET, $_POST, $_FILES și celelalte

> Superglobals PHP explicate: ce conțin $_GET, $_POST, $_FILES și $_SERVER, cum le umple PHP înaintea codului dumneavoastră și cum folosiți sigur datele.

Sursa: https://phpsos.de/ro/php/superglobals/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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

| Superglobal | Conținut | Proveniență |
|---|---|---|
| `$_GET` | parametri din adresă (query string) | client |
| `$_POST` | câmpurile formularului unei cereri POST | client |
| `$_FILES` | informații despre fișierele încărcate | client, pregătite de PHP |
| `$_COOKIE` | cookie-uri trimise de browser | client |
| `$_REQUEST` | amestec de GET, POST și, eventual, cookie-uri | client |
| `$_SERVER` | antetele cererii, metodă, căi, informații despre server | server web și client amestecate |
| `$_ENV` | variabile de mediu | server |
| `$_SESSION` | datele sesiunii curente | stocarea serverului |
| `$GLOBALS` | toate variabilele globale | script |

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](https://phpsos.de/ro/php/datei-uploads-intern/).

## 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
<?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](https://phpsos.de/ro/blog/eingaben-validieren-php/). Pentru datele de sesiune din `$_SESSION` se aplică reguli proprii; ele se află pe pagina [Sesiuni și cookie-uri în PHP](https://phpsos.de/ro/php/sessions-und-cookies/).

## Superglobals și PHP2Shell: ce se întâmplă înaintea codului dumneavoastră

Aici se află legătura cu situația actuală. [CVE-2026-109618](https://phpsos.de/ro/php2shell/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.

> **Acționați imediat:**
> Obligatorie este actualizarea la PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 și repornirea tuturor proceselor PHP. Măsurile provizorii de la php.net, de exemplu limite mai strânse pentru `post_max_size`, nu sunt o protecție completă.

## 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](https://phpsos.de/ro/leistungen/php-patch-service/).
- 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

**Câte superglobals există în PHP?**  
Manualul PHP menționează nouă: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST și $_ENV. Sunt disponibile în orice domeniu de vizibilitate, inclusiv în funcții și metode.

**Sunt valorile din $_SERVER de încredere?**  
Doar parțial. Intrările care încep cu HTTP_ provin din antetele cererii clientului. Manualul avertizează, de exemplu, că SERVER_NAME poate reflecta numele de gazdă furnizat de client și nu este de încredere pentru decizii de securitate.

**De ce este $_POST uneori gol, deși un formular a fost trimis?**  
Cauza cea mai frecventă este o cerere mai mare decât post_max_size. Atunci $_POST și $_FILES rămân, potrivit manualului, goale. La același rezultat duce și o setare enable_post_data_reading dezactivată.

**Ar trebui folosit $_REQUEST?**  
Mai bine nu. $_REQUEST amestecă date din surse diferite, iar ce sursă câștigă depinde de request_order și variables_order. Citiți valorile țintit din $_GET sau $_POST.

## Surse

- [Manualul PHP: superglobals](https://www.php.net/manual/de/language.variables.superglobals.php)
- [Manualul PHP: $_SERVER](https://www.php.net/manual/en/reserved.variables.server.php)
- [Manualul PHP: directivele php.ini](https://www.php.net/manual/de/ini.core.php)
- [Manualul PHP: request_parse_body](https://www.php.net/manual/en/function.request-parse-body.php)
