Superglobaler: $_GET, $_POST, $_FILES med flera

Kort sagt: Superglobaler är fördefinierade arrayer som PHP fyller automatiskt vid varje förfrågan och som finns tillgängliga överallt i koden. $_GET innehåller parametrarna från adressen, $_POST formulärdata, $_FILES uppladdade filer, $_COOKIE cookies och $_SERVER uppgifter om förfrågan och servern. PHP skapar de här arrayerna innan er applikationskod startar. Därför kan sårbarheter i just den bearbetningen, som vid PHP2Shell, inte fångas upp av kontroller i applikationen.

Vad är superglobaler?

I PHP gäller en variabel normalt bara i den funktion där den skapades. Superglobaler är undantaget: De är tillgängliga i varje giltighetsområde utan att man behöver hämta dem med global. PHP-manualen nämner nio av dem.

För icke-tekniker kan det beskrivas så: Superglobalerna är applikationens brevlåda. Allt som en besökare skickar hamnar där innan applikationen läser det. Och allt i brevlådan kommer potentiellt från en främling.

Superglobalerna i översikt

Särskilt lömsk är $_SERVER. Enligt manualen skapar PHP för varje förfrågningsrubrik en post som börjar med HTTP_, till exempel HTTP_USER_AGENT. De här värdena sätter klienten själv. Även SERVER_NAME kan enligt manualen innehålla det värdnamn som klienten har levererat och är inte tillförlitligt för säkerhetsbeslut.

Hur PHP fyller superglobalerna

Innan det första tecknet i ert skript körs har PHP redan arbetat. Det läser adressen, rubrikerna och förfrågans innehåll, delar upp dem och lägger resultaten i arrayerna. Flera inställningar styr det steget:

1. variables_order (standard EGPCS) avgör vilka superglobaler som över huvud taget skapas: Environment, GET, POST, Cookie, Server.
2. request_order (standard tom) bestämmer vad $_REQUEST bildas av. Är den tom gäller variables_order. De medföljande php.ini-filerna utelämnar enligt manualen cookies av säkerhetsskäl.
3. max_input_vars (standard 1000) och max_input_nesting_level (standard 64) begränsar antalet och nästlingen av indatavariabler.
4. post_max_size (standard 8M) begränsar förfrågans innehåll. Är en förfrågan större förblir $_POST och $_FILES tomma.
5. enable_post_data_reading (standard på) styr om PHP över huvud taget tolkar innehållet i POST-förfrågningar automatiskt.

Är enable_post_data_reading avstängd läser applikationen det råa innehållet själv via php://input. Sedan PHP 8.4.0 finns dessutom request_parse_body(), som tolkar formulär- och uppladdningsdata även för andra metoder än POST och medger egna gränsvärden. Hur uppladdningsdelen går till i detalj förklarar sidan Så bearbetar PHP filuppladdningar.

Hantera förfrågningsdata säkert

Grundsatsen är enkel: Varje värde från $_GET, $_POST, $_COOKIE, $_FILES och HTTP_-posterna i $_SERVER är en främmande inmatning. Det kontrolleras vid mottagandet och maskeras på lämpligt sätt vid utmatningen.

<?php
declare(strict_types=1);

// Heltal förväntas: kontrollera i stället för att blint omvandla
$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');
}

// Tillåt bara godkända värden
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Maskera alltid utmatningen
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

En vanlig snubbeltråd är uppgifter om en förfrågans ursprung. Står en reverse proxy, en lastbalanserare eller ett CDN framför webbservern innehåller $_SERVER['REMOTE_ADDR'] den förmedlarens adress, inte besökarens. Den verkliga adressen står då i en rubrik som X-Forwarded-For, som dock vilken klient som helst kan sätta själv. Applikationen får bara tolka sådana rubriker om förfrågan bevisligen kommer från en egen, känd proxy. Annars går det lätt att lura spärrar efter IP-adress eller loggar. Liknande gäller HTTPS: Slutar krypteringen vid proxyn måste applikationen uttryckligen veta att den ursprungliga anslutningen var krypterad.

Fler mönster för validering och filtrering visar artikeln Validera och filtrera indata i PHP. För sessionsdata i $_SESSION gäller egna regler; de står på sidan Sessioner och cookies i PHP.

Superglobaler och PHP2Shell: vad som sker före er kod

Här ligger kopplingen till det aktuella läget. CVE-2026-109618 beskriver att ett out-of-memory-tillstånd kan avbryta PHP medan förfrågningsdata bara delvis är initialiserade; vid uppstädningen av förfrågan kan ogiltiga data då behandlas som giltiga. Vid CVE-2026-109619 kan internt tillstånd från en förfrågan finnas kvar sedan minnet frigjorts och användas av en senare förfrågan i samma worker.

Båda sårbarheterna ligger alltså i den bearbetning som PHP självt utför kring förfrågan, inte i applikationskoden. PHP-teamet bedömer risken som högst vid mod_php; där visades en exploit innan någon applikationskod alls körs. Ingen filter_var() och ingen kontroll i applikationen kan förhindra det.

Hur hjälper PHP SOS konkret?

• Vi kontrollerar de verksamma gränsvärdena för förfrågningsdata per webbplats och sätter dem i linje med applikationen.
• Vi installerar PHP-uppdateringen, startar om alla workers och styrker patchnivån inom ramen för vår PHP-patchtjänst.
• Vi granskar egenutvecklade lösningar för att se om värden från superglobaler hamnar ogranskade i databas, filsystem eller utmatning.
• Vi säkrar webbserverloggarna från och med den 20 oktober 2026, så att en senare utvärdering förblir möjlig.

Vanliga frågor

Källor

• PHP-manualen: superglobaler
• PHP-manualen: $_SERVER
• PHP-manualen: php.ini-direktiv
• PHP-manualen: request_parse_body