Superglobals: $_GET, $_POST, $_FILES en co.

Kort gezegd: Superglobals zijn vooraf gedefinieerde arrays die PHP bij elk verzoek automatisch vult en die overal in de code beschikbaar zijn. $_GET bevat de parameters uit het adres, $_POST de formuliergegevens, $_FILES geüploade bestanden, $_COOKIE de cookies en $_SERVER gegevens over verzoek en server. PHP maakt deze arrays aan voordat uw toepassingscode start. Daarom kunnen lekken in precies deze verwerking, zoals bij PHP2Shell, niet door controles in de toepassing worden opgevangen.

Wat zijn superglobals?

In PHP geldt een variabele normaal gesproken alleen in de functie waarin ze is aangemaakt. Superglobals zijn de uitzondering: ze zijn in elk geldigheidsbereik beschikbaar, zonder dat men ze met global hoeft op te halen. De PHP-handleiding noemt er negen.

Voor niet-technici is dat zo te beschrijven: de superglobals zijn de brievenbus van de toepassing. Alles wat een bezoeker stuurt, belandt daar voordat de toepassing het leest. En alles in de brievenbus komt potentieel van een vreemde.

De superglobals in overzicht

Bijzonder verraderlijk is $_SERVER. Volgens de handleiding maakt PHP voor elke verzoekheader een vermelding met HTTP_ aan het begin, bijvoorbeeld HTTP_USER_AGENT. Deze waarden stelt de client zelf in. Ook SERVER_NAME kan volgens de handleiding de door de client geleverde hostnaam bevatten en is voor beveiligingsbeslissingen niet betrouwbaar.

Hoe PHP de superglobals vult

Voordat het eerste teken van uw script wordt uitgevoerd, heeft PHP al gewerkt. Het leest het adres, de headers en de inhoud van het verzoek, ontleedt ze en legt de resultaten in de arrays. Meerdere instellingen sturen deze stap aan:

1. variables_order (standaard EGPCS) bepaalt welke superglobals worden aangemaakt: Environment, GET, POST, Cookie, Server.
2. request_order (standaard leeg) bepaalt waaruit $_REQUEST wordt gevormd. Is het leeg, dan geldt variables_order. De meegeleverde php.ini-bestanden laten cookies volgens de handleiding om veiligheidsredenen weg.
3. max_input_vars (standaard 1000) en max_input_nesting_level (standaard 64) beperken aantal en nesting van de invoervariabelen.
4. post_max_size (standaard 8M) beperkt de verzoekinhoud. Is een verzoek groter, dan blijven $_POST en $_FILES leeg.
5. enable_post_data_reading (standaard aan) bepaalt of PHP de inhoud van POST-verzoeken automatisch verwerkt.

Is enable_post_data_reading uitgeschakeld, dan leest de toepassing de ruwe inhoud zelf via php://input. Sinds PHP 8.4.0 is er bovendien request_parse_body(), dat formulier- en uploadgegevens ook voor andere methoden dan POST verwerkt en eigen grenswaarden toestaat. Hoe het uploadgedeelte in detail verloopt, legt de pagina Hoe PHP bestandsuploads verwerkt uit.

Veilig omgaan met verzoekgegevens

Het uitgangspunt is eenvoudig: elke waarde uit $_GET, $_POST, $_COOKIE, $_FILES en de HTTP_-vermeldingen van $_SERVER is een vreemde invoer. Ze wordt bij aanname gecontroleerd en bij uitvoer passend geëscaped.

<?php
declare(strict_types=1);

// Geheel getal verwacht: controleren in plaats van blind omzetten
$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');
}

// Alleen toegestane waarden toelaten
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Uitvoer altijd escapen
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Een veelvoorkomend struikelblok zijn gegevens over de herkomst van een verzoek. Staat vóór de webserver een reverse proxy, een load balancer of een CDN, dan bevat $_SERVER['REMOTE_ADDR'] het adres van die tussenpersoon, niet dat van de bezoeker. Het echte adres staat dan in een header als X-Forwarded-For, die echter elke client zelf kan instellen. De toepassing mag zulke headers alleen verwerken als het verzoek aantoonbaar van een eigen, bekende proxy komt. Anders zijn blokkades op IP-adres of logboeken gemakkelijk te misleiden. Iets vergelijkbaars geldt voor HTTPS: eindigt de versleuteling bij de proxy, dan moet de toepassing uitdrukkelijk weten dat de oorspronkelijke verbinding versleuteld was.

Verdere patronen voor validatie en filtering toont het artikel Invoer in PHP valideren en filteren. Voor sessiegegevens in $_SESSION gelden eigen regels; ze staan op de pagina Sessies en cookies in PHP.

Superglobals en PHP2Shell: wat vóór uw code gebeurt

Hier ligt het verband met de actuele situatie. CVE-2026-109618 beschrijft dat een out-of-memory-toestand PHP kan onderbreken terwijl verzoekgegevens maar gedeeltelijk zijn geïnitialiseerd; bij het opruimen van het verzoek kunnen ongeldige gegevens dan als geldig worden behandeld. Bij CVE-2026-109619 kan de interne toestand van een verzoek na het vrijgeven van het geheugen blijven bestaan en door een later verzoek in dezelfde worker worden gebruikt.

Beide lekken zitten dus in de verwerking die PHP zelf rond het verzoek uitvoert, niet in de toepassingscode. Het PHP-team schat het risico bij mod_php het hoogst in; daar is een exploit gedemonstreerd voordat er ook maar toepassingscode draait. Geen enkele filter_var() en geen enkele controle in de toepassing kan dat voorkomen.

Hoe helpt PHP SOS concreet?

• Wij controleren de werkzame grenswaarden voor verzoekgegevens per website en stellen ze passend bij de toepassing in.
• Wij installeren de PHP-update, starten alle workers opnieuw en leggen de patchstand vast in het kader van onze PHP-patchservice.
• Wij controleren maatwerk erop of waarden uit superglobals ongecontroleerd in database, bestandssysteem of uitvoer terechtkomen.
• Wij beveiligen de weblogs vanaf 20-10-2026, zodat een latere analyse mogelijk blijft.

Veelgestelde vragen

Bronnen

• PHP-handleiding: superglobals
• PHP-handleiding: $_SERVER
• PHP-handleiding: php.ini-directives
• PHP-handleiding: request_parse_body