# Superglobaler: $_GET, $_POST, $_FILES med flera

> PHP-superglobaler förklarade: vad som finns i $_GET, $_POST, $_FILES, $_SERVER med flera, hur PHP fyller dem före er kod och hur ni använder förfrågningsdata säkert.

Källa: https://phpsos.de/sv/php/superglobals/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**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

| Superglobal | Innehåll | Ursprung |
|---|---|---|
| `$_GET` | parametrar från adressen (query string) | klient |
| `$_POST` | formulärfält i en POST-förfrågan | klient |
| `$_FILES` | uppgifter om uppladdade filer | klient, bearbetade av PHP |
| `$_COOKIE` | cookies som webbläsaren skickar med | klient |
| `$_REQUEST` | blandning av GET, POST och eventuellt cookies | klient |
| `$_SERVER` | förfrågningsrubriker, metod, sökvägar, serveruppgifter | webbserver och klient blandat |
| `$_ENV` | miljövariabler | server |
| `$_SESSION` | data i den aktuella sessionen | serverlagring |
| `$GLOBALS` | alla globala variabler | skript |

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](https://phpsos.de/sv/php/datei-uploads-intern/).

## 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
<?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](https://phpsos.de/sv/blog/eingaben-validieren-php/). För sessionsdata i `$_SESSION` gäller egna regler; de står på sidan [Sessioner och cookies i PHP](https://phpsos.de/sv/php/sessions-und-cookies/).

## Superglobaler och PHP2Shell: vad som sker före er kod

Här ligger kopplingen till det aktuella läget. [CVE-2026-109618](https://phpsos.de/sv/php2shell/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.

> **Agera direkt:**
> Skyldigheten är uppdateringen till PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 och omstart av alla PHP-processer. Övergångsåtgärderna från php.net, till exempel snävare gränser för `post_max_size`, är inget fullständigt skydd.

## 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](https://phpsos.de/sv/leistungen/php-patch-service/).
- 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

**Hur många superglobaler finns det i PHP?**  
PHP-manualen nämner nio: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST och $_ENV. De är tillgängliga i varje giltighetsområde, även i funktioner och metoder.

**Är värden i $_SERVER tillförlitliga?**  
Bara delvis. Poster som börjar med HTTP_ kommer från klientens förfrågningsrubriker. Manualen varnar till exempel för att SERVER_NAME kan återge det värdnamn som klienten har levererat och inte är tillförlitligt för säkerhetsbeslut.

**Varför är $_POST ibland tom fast ett formulär skickades?**  
Vanligaste orsaken är en förfrågan som är större än post_max_size. Då förblir $_POST och $_FILES enligt manualen tomma. Även en avstängd inställning enable_post_data_reading leder till det.

**Bör man använda $_REQUEST?**  
Helst inte. $_REQUEST blandar data från olika källor, och vilken källa som vinner beror på request_order och variables_order. Läs värden riktat ur $_GET eller $_POST.

## Källor

- [PHP-manualen: superglobaler](https://www.php.net/manual/de/language.variables.superglobals.php)
- [PHP-manualen: $_SERVER](https://www.php.net/manual/en/reserved.variables.server.php)
- [PHP-manualen: php.ini-direktiv](https://www.php.net/manual/de/ini.core.php)
- [PHP-manualen: request_parse_body](https://www.php.net/manual/en/function.request-parse-body.php)
