Superglobals: $_GET, $_POST, $_FILES m.fl.

Kort sagt: Superglobals er foruddefinerede arrays, som PHP automatisk udfylder ved hver forespørgsel, og som er tilgængelige overalt i koden. $_GET indeholder parametrene fra adressen, $_POST formulardataene, $_FILES uploadede filer, $_COOKIE cookies og $_SERVER oplysninger om forespørgsel og server. PHP opretter disse arrays, før jeres applikationskode starter. Derfor kan sårbarheder netop i denne behandling, som ved PHP2Shell, ikke opfanges af kontroller i applikationen.

Hvad er superglobals?

I PHP gælder en variabel normalt kun i den funktion, hvor den blev oprettet. Superglobals er undtagelsen: De står til rådighed i ethvert gyldighedsområde, uden at man skal hente dem med global. PHP-manualen nævner ni af dem.

For ikke-teknikere kan det beskrives sådan: Superglobals er applikationens postkasse. Alt, hvad en besøgende sender, havner dér, før applikationen læser det. Og alt i postkassen stammer potentielt fra en fremmed.

Superglobals i overblik

Særligt snedig er $_SERVER. Ifølge manualen opretter PHP for hver forespørgsels-header en post med HTTP_ i begyndelsen, f.eks. HTTP_USER_AGENT. Disse værdier sætter klienten selv. Også SERVER_NAME kan ifølge manualen indeholde det værtsnavn, klienten har leveret, og er ikke pålidelig til sikkerhedsbeslutninger.

Hvordan PHP udfylder superglobals

Før det første tegn i jeres script udføres, har PHP allerede arbejdet. Det læser adressen, headerne og forespørgslens indhold, opdeler dem og lægger resultaterne i arraysene. Flere indstillinger styrer dette trin:

1. variables_order (standard EGPCS) fastlægger, hvilke superglobals der overhovedet oprettes: Environment, GET, POST, Cookie, Server.
2. request_order (standard tom) bestemmer, hvad $_REQUEST dannes af. Er den tom, gælder variables_order. De medfølgende php.ini-filer udelader ifølge manualen cookies af sikkerhedsgrunde.
3. max_input_vars (standard 1000) og max_input_nesting_level (standard 64) begrænser antal og indlejring af inputvariabler.
4. post_max_size (standard 8M) begrænser forespørgslens indhold. Er en forespørgsel større, forbliver $_POST og $_FILES tomme.
5. enable_post_data_reading (standard til) styrer, om PHP overhovedet automatisk behandler indholdet af POST-forespørgsler.

Er enable_post_data_reading slået fra, læser applikationen det rå indhold selv via php://input. Siden PHP 8.4.0 findes desuden request_parse_body(), som behandler formular- og uploaddata også for andre metoder end POST og tillader egne grænseværdier. Hvordan upload-delen forløber i detaljer, forklarer siden Sådan behandler PHP filuploads.

Håndtér forespørgselsdata sikkert

Princippet er enkelt: Hver værdi fra $_GET, $_POST, $_COOKIE, $_FILES og HTTP_-posterne i $_SERVER er et fremmed input. Den kontrolleres ved modtagelsen og maskeres passende ved udskrivningen.

<?php
declare(strict_types=1);

// Heltal forventet: kontrollér i stedet for at omdanne blindt
$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');
}

// Tillad kun tilladte værdier
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Maskér altid ved udskrivning
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

En hyppig snublesten er oplysninger om en forespørgsels oprindelse. Står der foran webserveren en reverse proxy, en load balancer eller et CDN, indeholder $_SERVER['REMOTE_ADDR'] mellemleddets adresse, ikke den besøgendes. Den rigtige adresse står så i en header som X-Forwarded-For, som dog enhver klient selv kan sætte. Applikationen må kun behandle sådanne headere, hvis forespørgslen påviseligt kommer fra en egen, kendt proxy. Ellers kan spærringer efter IP-adresse eller protokoller let snydes. Noget lignende gælder for HTTPS: Slutter krypteringen ved proxyen, skal applikationen udtrykkeligt vide, at den oprindelige forbindelse var krypteret.

Yderligere mønstre til validering og filtrering viser indlægget Valider og filtrér input i PHP. For sessionsdata i $_SESSION gælder egne regler; de står på siden Sessioner og cookies i PHP.

Superglobals og PHP2Shell: hvad der sker før jeres kode

Her ligger sammenhængen med den aktuelle situation. CVE-2026-109618 beskriver, at en out-of-memory-tilstand kan afbryde PHP, mens forespørgselsdata kun er delvis initialiseret; ved oprydningen af forespørgslen kan ugyldige data så blive behandlet som gyldige. Ved CVE-2026-109619 kan en forespørgsels interne tilstand blive bestående, efter at hukommelsen er frigivet, og blive udnyttet af en senere forespørgsel i den samme worker.

Begge sårbarheder ligger altså i den behandling, PHP selv udfører omkring forespørgslen, ikke i applikationskoden. PHP-teamet vurderer risikoen ved mod_php som den højeste; dér blev en exploit vist, før der overhovedet kører applikationskode. Ingen filter_var() og ingen kontrol i applikationen kan forhindre det.

Hvordan hjælper PHP SOS konkret?

• Vi kontrollerer de virksomme grænseværdier for forespørgselsdata pr. website og sætter dem passende til applikationen.
• Vi indspiller PHP-opdateringen, genstarter alle workere og dokumenterer patch-status som led i vores PHP-patchservice.
• Vi kontrollerer egenudviklinger for, om værdier fra superglobals uden kontrol når ind i database, filsystem eller output.
• Vi sikrer webserverens logs fra og med den 20.10.2026, så en senere analyse forbliver mulig.

Ofte stillede spørgsmål

Kilder

• PHP-manualen: Superglobals
• PHP-manualen: $_SERVER
• PHP-manualen: php.ini-direktiver
• PHP-manualen: request_parse_body