Filrättigheter på webbservern

Kort sagt: För filrättigheter på webbservern gäller en grundprincip: Användaren som PHP körs under får läsa sin egen kod men inte ändra den. Skrivrätt får bara uppladdnings-, cache- och temp-mappar, och där körs ingen PHP. Rättigheter som 777 har inget på en produktionsserver att göra.

Varför filrättigheter gör skillnad efter ett intrång

När angripare via en sårbarhet kör kod på en server körs den koden med PHP-processens rättigheter. Det den användaren får göra får också angriparen göra. Just här avgörs om ett intrång blir en bestående bakdörr.

Med PHP2Shell har det scenariot blivit mycket konkret i oktober 2026. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det möjligt att köra skadlig kod utan inloggning. De är åtgärdade sedan den 21 oktober 2026 i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Bra filrättigheter förhindrar inget angrepp, men de hindrar insmugglad kod från att bestående skriva om er applikation.

I många installationer tillhör hela koden webbserverns användare, så att uppdateringar fungerar med ett knapptryck. Det är bekvämt men precis den konstellation som angripare söker.

Grundprincipen: separera ägare och körningsanvändare

Förnuftigt är en uppdelning i två roller. En ägare, till exempel en deploy-användare, äger filerna och installerar uppdateringar. PHP-processen körs under en annan användare och har bara läsrätt via gruppen.

Själva webbservern, till exempel Nginx, behöver vid PHP-FPM bara läsåtkomst till statiska filer som bilder och CSS. Den åtkomsten får ni via gruppen eller en riktad åtkomstregel. Den som driver flera webbplatser ger var och en en egen körningsanvändare; hur det samspelar med pooler står i guiden open_basedir och isolering per webbplats.

Kontrollera filrättigheter på webbservern

Innan ni ändrar något bör ni skaffa en överblick. Följande kommandon ändrar ingenting.

# Under vilken användare körs PHP-processerna?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Filer och mappar som alla får skriva i
find /var/www -perm -o+w -ls

# Filer som ägs av webbserverns användare (exempel www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Rättigheter för konfigurationsfilerna
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null

Poster som alla får skriva i är nästan alltid ett fel. PHP-filer som ägs av körningsanvändaren visar att den kan ändra sin kod. Misstänkta är dessutom enskilda filer vars ägare eller rättigheter avviker från grannfilerna. Det kan vara ett tecken på insmugglade filer, som beskrivs i guiden Upptäcka och ta bort webshell.

Rätta rättigheterna: steg för steg

Ändra rättigheter bara efter en säkerhetskopia och helst först i en testmiljö. Vid misstanke om intrång bör ni säkra spåren först, för ägare och tidsstämplar är då bevismaterial.

SITE=/var/www/seite1
# Ägare: deploy-användaren, grupp: körningsanvändaren
sudo chown -R deploy:seite1 "$SITE"
# Mappar 750, filer 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Bara de här mapparna får PHP skriva i (anpassa sökvägarna till applikationen)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"

Kontrollera därefter webbplatsen fullständigt: startsida, inloggning, formulär, bilduppladdning, cacher. Vilka mappar en applikation måste kunna skriva i står i tillverkarens systemkrav på tillverkarens officiella sida.

Förhindra PHP-körning i skrivbara mappar

Skrivrättigheter är bara hälften så farliga om ingen kod kan köras där. Spärra körning av PHP i uppladdnings- och cachemappar på webbserverns nivå. För Apache i VirtualHost-konfigurationen:

<Directory "/var/www/seite1/public/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

För Nginx räcker ett location-block som avvisar förfrågningar till PHP-filer i de mapparna. Regeln hör hemma i serverkonfigurationen, inte i en .htaccess i uppladdningsmappen, som en angripare med skrivrättigheter kunde ändra igen.

Som komplement lönar det sig att titta på deploy-användarens umask, så att nya filer inte automatiskt skapas för öppet. Värdet 027 ger 640 för filer och 750 för mappar. På egna servrar ligger det ansvaret helt hos er; vad som i övrigt ingår beskriver Säkra root-servrar och vServers själv.

Specialfall: hostingpaneler, delat webbhotell och deployments

Alla servrar går inte att sätta upp enligt läroboken. Hostingpaneler som Plesk eller cPanel skapar egna användare och rättigheter och återställer dem vid vissa åtgärder. Ändra rättigheter där helst via panelens funktioner eller kontrollera efter panelens uppdateringar om era inställningar fortfarande gäller.

Vid delat webbhotell har ni oftast bara en användare för allt. En separation av ägare och körningsanvändare är då inte möjlig. Desto viktigare är snäva rättigheter på konfigurationsfiler, inga 777-rättigheter och att stänga av PHP-körning i uppladdningsmappar, så långt webbhotellet tillåter det.

Den som arbetar med automatiska deployments bör sätta rättigheterna i själva deployment-skriptet. Annars återställer varje ny version det gamla, alltför öppna läget. En kort kontroll i slutet av deploymenten, till exempel med kommandot för skrivbara filer ovan, fångar sådana bakslag tillförlitligt och går att bygga in i varje pipeline utan större arbete.

Hur hjälper PHP SOS konkret?

• Vi kartlägger ägare, rättigheter och körningsanvändare för alla webbplatser på servern.
• Vi fastställer ett rättighetskoncept som passar er applikation och er uppdateringsväg.
• Vi genomför rättigheter och körningsspärrar och testar webbplatsen fullständigt efteråt.
• Vi dokumenterar konceptet så att deployments och uppdateringar inte luckrar upp det igen.

Hur det ingår i ett varaktigt skydd beskriver tjänsten Serverhärdning för PHP-webbservrar.

Vanliga frågor

Källor

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