Kort sagt: På en live-webbplats hör display_errors = Off hemma i php.ini, tillsammans med display_startup_errors = Off, log_errors = On och en fellogg utanför webbroten. Dessutom måste CMS och ramverk köras i produktionsläge, annars visar deras egna felsidor detaljerna. Spärrat med php_admin_flag och kontrollerat efter varje uppdatering stannar felen i loggen i stället för att hamna i webbläsaren.
Vad ett enda felmeddelande avslöjar
En varning överst på sidan, ett ”Fatal error” i stället för orderöversikten: sådana utskrifter ser ofarliga ut. För en angripare är de en karta. De visar fullständiga filsökvägar, namn på databaser och tabeller, använda bibliotek och ofta PHP-versionen.
Särskilt i lägen som PHP2Shell, där det söks i massor efter sårbara servrar, bör en server avslöja så lite som möjligt om sig själv. Det stänger ingen sårbarhet i PHP-tolken, men försvårar varje fortsatt steg efter ett intrång och gör riktade angrepp mot er applikation mödosammare.
Därtill kommer dataskyddet. Felmeddelanden kan innehålla delar av förfrågningar, till exempel e-postadresser från formulär. Det som visas i en besökares webbläsare står inte längre under er kontroll.
Standardvärdena är inte avsedda för produktion
Många utgår från att PHP döljer fel av sig självt. PHP-manualen säger något annat: det inbyggda standardvärdet för display_errors är 1, och display_startup_errors är sedan PHP 8.0 likaså påslaget som standard. Först den medföljande mallen php.ini-production sätter båda till Off. Manualen kallar uttryckligen display_errors en utvecklingsfunktion som aldrig bör användas på system på internet.
Att er server använder produktionsmallen är inte självklart. Container-images startar ibland helt utan php.ini, webbhotellspaneler sätter egna värden, och efter en flytt kopieras gärna utvecklingsmallen.
display_errors off: inställningarna i överblick
Värdena nedan är rimliga för produktionsservrar. Konstanter som E_ALL fungerar bara i php.ini; i Apache-konfigurationen saknar de enligt PHP-manualen betydelse och måste anges som tal.
| Inställning | Produktion | Syfte |
|---|---|---|
display_errors |
Off |
inga fel i webbläsaren |
display_startup_errors |
Off |
inga fel vid PHP:s start i utdata |
log_errors |
On |
skriv fel till loggen |
error_log |
sökväg utanför webbroten | egen loggfil per webbplats eller pool |
error_reporting |
E_ALL |
logga alla fel, visa dem inte |
html_errors |
Off |
klartext i stället för HTML i loggar |
zend.exception_ignore_args |
On |
inga funktionsargument i stacktraces |
fatal_error_backtraces |
0 fram till uppdateringen (bara PHP 8.5) |
övergångsåtgärd enligt php.net |
zend.exception_ignore_args är särskilt värdefull. Utan den inställningen kan stacktraces i loggar och på felsidor innehålla argumenten till funktionsanrop, alltså även lösenord eller tokens som just bearbetades.
; php.ini för webb-SAPI
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/website-fehler.log
error_reporting = E_ALL
html_errors = Off
zend.exception_ignore_args = On
; bara PHP 8.5, övergångsåtgärd fram till uppdateringen till 8.5.12:
; fatal_error_backtraces = 0
I FPM-poolen spärrar ni dessutom de viktigaste värdena så att ingen applikation slår på dem igen med ini_set():
; t.ex. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[display_errors] = off
php_admin_flag[display_startup_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php/seite1-fehler.log
Starta därefter om respektive PHP-tjänst. Hur spärrandet exakt fungerar förklarar inlägget php_admin_value: spärra inställningar mot överskrivning. En fullständig grundkonfiguration finns under Konfigurera php.ini säkert.
Den andra strömbrytaren: applikationens felsökningsläge
PHP är bara halva jobbet. Moderna ramverk fångar fel själva och visar egna, ofta mycket utförliga felsidor. I felsökningsläge innehåller de källkodsutdrag, konfigurationsvärden och ibland miljövariabler. Dessa sidor visas även när display_errors är avstängd i PHP.
Kontrollera därför varje applikations egen strömbrytare. I WordPress är det WP_DEBUG och WP_DEBUG_DISPLAY i wp-config.php, i Laravel och Symfony APP_DEBUG och miljön i .env-filen, i andra system produktionsläget enligt tillverkarens dokumentation. På ett live-system hör felsökningsläget permanent hemma av, även ”bara kort för att testa” är en risk.
Hur fel hanteras ordentligt i applikationen i stället för att undertryckas beskriver Fel och exceptions i PHP.
Så hittar ni felutskrifter innan andra gör det
Att ställa in en gång räcker inte. Felutskrifter kommer tillbaka efter uppdateringar, flyttar eller paneländringar. Ett kort kontrollförlopp hjälper:
- Kontrollera de verksamma värdena i webbkontexten, inte bara på kommandoraden, till exempel med en kort utlagd kontrollfil som raderas direkt efteråt.
- Kontrollera varje applikations felsökningsläge i dess konfigurationsfil.
- Sök igenom levererade sidor efter typiska felstexter, som i kodblocket nedan.
- Sök i sökmotorn med en
site:-fråga mot er domän efter termer som ”Fatal error” eller ”Warning”. - Kontrollera att felloggen skrivs och inte ligger i webbroten.
# Sök igenom levererade sidor efter PHP-felstexter (bara egna domäner)
for url in https://www.example.de/ https://www.example.de/kontakt/; do
curl -s "$url" | grep -E -o "(Fatal error|Warning|Notice|Deprecated|Stack trace)[^<]{0,80}" | head -3
done
# Skrivs felloggen?
ls -l /var/log/php/
Att dölja fel är ingen ersättning för att åtgärda dem. En logg full av varningar är ett tecken på underhållsbehov, och efter ett intrång är den ofta ett viktigt spår. Vad ni loggar och vad ni inte loggar beskriver Logga säkert: logga fel utan dataläckage.
Slutsats: tyst i webbläsaren, pratsam i loggen
Regeln för produktionsservrar är enkel: fel hör hemma i loggen, inte på webbplatsen. I praktiken faller den på standardvärden som inte är avsedda för produktion, på felsökningsbrytare i applikationer och på konfigurationer som faller tillbaka efter uppdateringar eller flyttar.
Den som stänger av display_errors och display_startup_errors, spärrar värdena i poolen, kontrollerar applikationens felsökningsläge och regelbundet kontrollerar resultatet stänger en av de vanligaste källorna till onödig informationsspridning. Arbetsinsatsen är liten och effekten håller i sig så länge kontrollen förblir en del av varje uppdatering.
En punkt bör inte hamna i skymundan: felloggen är ingen papperskorg. Den som läser den regelbundet upptäcker felaktiga uppdateringar, föråldrade funktioner och ibland också de första spåren av ett angrepp, långt innan kunder märker något.
Hur hjälper PHP SOS konkret?
- Kontrollera: Vi läser ut de verksamma felinställningarna per webbplats och pool och söker igenom levererade sidor efter felutskrifter.
- Ställa om: Vi sätter PHP- och applikationsinställningar för produktionsdrift och spärrar dem mot överskrivning.
- Inrätta loggar: Felloggar ligger utanför webbroten, roteras och är åtkomliga för era utvecklare.
- Hålla permanent: Inom ramen för säkerhetsunderhållsavtalet kontrollerar vi inställningarna på nytt efter varje uppdatering.
Vanliga frågor
Är inte display_errors i PHP redan avstängd?
Inte automatiskt. Enligt PHP-manualen är det inbyggda standardvärdet för display_errors 1. Först den medföljande mallen php.ini-production sätter Off. Om er server använder den mallen beror på distribution, panel eller container-image och bör kontrolleras.
Räcker display_errors = Off om WordPress eller Laravel körs i felsökningsläge?
Nej. Många CMS och ramverk har egna felsidor som kan visa detaljer oberoende av PHP. Stäng därför även av applikationens felsökningsläge, till exempel WP_DEBUG_DISPLAY i WordPress eller APP_DEBUG i Laravel och Symfony.
Vart tar felen vägen när de inte längre visas?
Med log_errors = On skriver PHP dem till den fil som error_log anger, eller till loggen för respektive driftläge, till exempel Apache- eller PHP-FPM-felloggen. Filen bör ligga utanför webbroten och roteras regelbundet.
Vad har fatal_error_backtraces med PHP2Shell att göra?
Inställningen finns från och med PHP 8.5 och är aktiv som standard. php.net nämner fatal_error_backtraces=0 med efterföljande omstart som en av övergångsåtgärderna för PHP 8.5 så länge uppdateringen till 8.5.12 återstår. Den ersätter inte uppdateringen.