open_basedir och isolering per webbplats

Kort sagt: open_basedir begränsar vilka kataloger PHP får komma åt. Ensamt är det bara en extra spärr. Verksam isolering per webbplats uppstår först i samspelet: egen systemanvändare, egen PHP-FPM-pool, egen temp-mapp och egna databasåtkomster. Då förblir ett intrång i en webbplats begränsat till just den webbplatsen.

Varför isolering avgör skadan efter PHP2Shell

På många servrar körs flera webbplatser sida vid sida: företagssidan, en butik, en gammal kampanjsida, hos byråer ofta dussintals kundprojekt. Ofta delar de på en systemanvändare och en PHP-process. Komprometteras en av dem ligger alla de andra öppna.

PHP2Shell gör den risken påtaglig. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det möjligt att köra skadlig kod utan inloggning, oberoende av CMS. Enligt mediarapporter gjordes ett första angreppsförsök redan den 17 oktober 2026, patcharna följde den 21 oktober. Lösningen är uppdateringen. Om ett angrepp under tiden dessförinnan drabbar en eller tio webbplatser avgör dock isoleringen.

Särskilt vid den andra sårbarheten tillkommer en ytterligare tanke: Enligt PHP-projektet kan internt tillstånd från en förfrågan finnas kvar i en worker och användas av en senare förfrågan i samma worker. Separata pooler per webbplats gör att webbplatser ändå inte delar workers.

Vad open_basedir åstadkommer

Med open_basedir fastställer ni en lista med kataloger. PHP:s filfunktioner som fopen, include eller file_get_contents vägrar då åtkomst till allt utanför listan. Ett insmugglat skript kan därmed inte utan vidare läsa konfigurationsfilerna för grannwebbplatsen.

Gränserna är viktiga: Kontrollen sker inne i PHP. Program som startas utanför PHP omfattas inte av den, och fel i tolken kan kringgå den. Därför hör open_basedir alltid ihop med spärrade systemfunktioner, så som beskrivs i guiden Använda disable_functions rätt, och framför allt med separation på operativsystemsnivå.

Isolering per webbplats i fyra lager

En hållbar separation bygger på flera lager. Varje lager fångar upp det som det föregående inte klarar.

Vid högt skyddsbehov, till exempel för butiker med betalningshantering eller portaler med hälsouppgifter, tillkommer containrar eller separata servrar.

Konfigurera open_basedir i PHP-FPM-poolen

Följande exempel visar en pool för en webbplats med egen användare seite1. Sökvägar och versionsnummer anpassar ni till ert system.

; /etc/php/8.3/fpm/pool.d/seite1.conf
[seite1]
user = seite1
group = seite1
listen = /run/php/seite1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = ondemand
pm.max_children = 10

php_admin_value[open_basedir] = /var/www/seite1/:/var/www/seite1-tmp/
php_admin_value[upload_tmp_dir] = /var/www/seite1-tmp/
php_admin_value[sys_temp_dir] = /var/www/seite1-tmp/
php_admin_value[session.save_path] = /var/www/seite1-tmp/sessions
php_admin_value[error_log] = /var/log/php/seite1.error.log
php_admin_flag[session.upload_progress.enabled] = off

Sista raden sätter samtidigt php.nets tillfälliga åtgärd mot PHP2Shell. Den fungerar bara från pool, php.ini eller serverkonfiguration, inte via ini_set() eller .user.ini. Mapparna skapar ni med lämpliga rättigheter:

sudo useradd --system --home /var/www/seite1 --shell /usr/sbin/nologin seite1
sudo mkdir -p /var/www/seite1-tmp/sessions
sudo chown -R seite1:seite1 /var/www/seite1-tmp
sudo chmod 700 /var/www/seite1-tmp

Hur rättigheterna i själva webbkatalogen bör se ut beskriver guiden Filrättigheter på webbservern.

Koppla in webbservern och kontrollera resultatet

I Nginx pekar varje webbplats på sin egen socket. Då hamnar ingen förfrågan i en annan webbplats pool.

server {
    server_name seite1.example;
    root /var/www/seite1/public;

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/seite1.sock;
    }
}

Fler anvisningar om den här kombinationen finns under Skydda Nginx med PHP-FPM. Efter omstarten kontrollerar ni att poolerna verkligen körs åtskilda:

sudo systemctl restart php8.3-fpm
# Varje pool bör köras under sin egen användare
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"

Testa därefter alla funktioner på webbplatsen: uppladdningar, bildbehandling, cacher, schemalagda uppgifter. Felmeddelanden med hänvisning till open_basedir restriction i felloggen visar vilken sökväg som fortfarande saknas. Lägg bara till sökvägar som applikationen verkligen behöver, och aldrig hela filsystemet.

Typiska fallgropar vid omställningen

Omställningen till separata pooler går att planera men har några återkommande fällor. Den vanligaste gäller delade bibliotek: Ligger till exempel ett ramverk eller en mapp med typsnitt utanför webbplatsens katalog måste den sökvägen läggas till för läsning i open_basedir. Bättre är att hämta in sådana beroenden i själva projektet.

Den andra fällan är sessioner. Byter lagringsplatsen loggas alla besökare ut en gång och pågående varukorgar går förlorade. Planera därför omställningen i ett lugnt tidsfönster och kungör den internt.

För det tredje körs schemalagda uppgifter ofta via kommandoraden och därmed under en annan användare än webbplatsen. Kontrollera cronjobb och köer och låt dem köras under den nya webbplatsanvändaren, annars uppstår filer med fel ägare som PHP senare inte får ändra.

Slutligen bör varje pool ha egna gränser för processer och minne. En webbplats som får hög belastning eller utsätts för angrepp kan då inte dra ned de andra.

Hur hjälper PHP SOS konkret?

• Vi kartlägger vilka webbplatser som i dag delar användare, processer och databaser.
• Vi sätter upp egna användare, pooler, temp-mappar och databasåtkomster för varje webbplats, utan att ändra applikationerna.
• Vi testar varje webbplats efter omställningen och åtgärdar saknade sökvägar riktat.
• Vi dokumenterar separationen som mall för framtida projekt.

Hur det passar in i ett helhetskoncept beskriver tjänsten Serverhärdning för PHP-webbservrar.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• OWASP Cheat Sheet Series
• BSI IT-Grundschutz