Logga säkert: logga fel utan dataläckage

Kort sagt: Loggning i PHP med dataskydd i åtanke innebär: dokumentera säkerhetsrelevanta händelser fullständigt men skriv aldrig lösenord, tokens, sessionsidentifierare och känsliga kunddata i loggen. Fel hör hemma i loggen, inte på skärmen, loggar ligger utanför webbroten och är skyddade mot ändring. Hur länge loggar sparas avgör ni medvetet tillsammans med dataskyddsombudet.

Mellan spårsäkring och dataläckage

Efter PHP2Shell rådde fackmedier att spara webbserverloggar från och med den 20 oktober 2026. Den som ville genomföra det upptäckte ofta två saker. Antingen hade loggarna sedan länge roterats och raderats. Eller så innehöll de saker som aldrig borde ha stått där: fullständiga formulärinmatningar, lösenord från misslyckade inloggningar, API-nycklar i URL:er.

Båda är ett problem. Utan loggar går en incident knappast att rekonstruera. Med för mycket innehåll blir loggen själv ett mål, för den som får åtkomst till servern läser gärna med. God loggning ligger däremellan: tillräckligt för spårsökning, så lite skyddsvärda data som möjligt.

Vad en PHP-applikation bör logga

OWASP Logging Cheat Sheet nämner händelser som räknas för säkerhet och spårbarhet. För typiska PHP-applikationer kan de sammanfattas så här:

Varje post bör besvara frågorna när, var, vem och vad: tidsstämpel, applikation och värd, källadress, användaridentifierare, typ av händelse och resultat. Namn eller e-postadresser går ofta att maskera eller ersätta med en intern identifierare utan att nyttan går förlorad.

Två källor till oönskade data i loggen förbises ofta. Den första är URL:er: Står ett token, en nyckel för lösenordsåterställning eller en e-postadress i query-strängen hamnar den automatiskt i webbserverns åtkomstlogg, i proxyloggar och i webbläsarhistoriken. Sådana värden hör hemma i request body eller en header, inte i adressen. Den andra källan är felsökningsläget. Ramverk och tillägg skriver i felsökningsdrift ofta med fullständiga förfrågningar, databasfrågor och miljövariabler. Förblir det läget aktivt efter en felsökning växer omärkligt en fil med precis den information som en angripare söker. Kontrollera efter varje felsökning att felsökningsutdata är avstängda igen och radera de filer som uppstod.

Loggning i PHP: grundinställningarna

Den första nivån är PHP självt. I produktion ska fel loggas men inte skrivas ut. Loggen ligger utanför webbroten så att den inte går att hämta via en URL.

; php.ini eller FPM-pool för produktion
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Varför synliga fel är farliga beskriver Stäng av felutskrifter i produktion. Hur fel och exceptions hänger ihop i PHP förklarar Fel och exceptions i PHP.

Den andra nivån är applikationen. Många ramverk använder för det ett bibliotek enligt standarden PSR-3 från PHP-FIG, som fastlägger ett enhetligt logger-gränssnitt. Viktigt är inte biblioteket utan disciplinen: välj kontextdata medvetet i stället för att skriva hela förfrågningar eller objekt i loggen.

<?php
// Avgifta och maskera inmatning före loggning
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // aldrig: 'passwort' => $_POST['passwort']
]);

Loginjektion och manipulerade poster

Skriver en applikation inmatning ofiltrerat i loggen kan en angripare skapa förfalskade poster med radbrytningar. Det förvirrar analysen och kan dölja spår. OWASP:s cheat sheet rekommenderar strukturerade format som JSON, borttagning eller kodning av radbrytningar och en längdbegränsning för inmatning i loggen.

Lika viktigt är skyddet av själva loggarna:

1. Lagring utanför webbroten och med rättigheter som webbserveranvändaren behöver för att skriva men inte för att radera gamla filer.
2. Kopia på ett andra system, till exempel via syslog över en krypterad anslutning. Den som tar över servern ska inte bara kunna radera spåren.
3. Begränsa läsåtkomsten och logga den själv. Loggar innehåller nästan alltid personuppgifter.
4. Upptäck bortfall: Blir loggen plötsligt tom är det en varningssignal.
5. Synkronisera klockan: Alla servrar hämtar tiden från samma källa och skriver en entydig tidszon i loggen. Annars går poster från webbserver, PHP och databas efter en incident knappast att foga samman till en tidslinje.

Besluta medvetet om lagring och dataskydd

Hur länge loggar får och måste finnas kvar är en avvägning mellan säkerhetsintresse, dataminimering och lagstadgade eller avtalsenliga föreskrifter. Art. 32 GDPR kräver tekniska och organisatoriska åtgärder som står i proportion till risken, bland annat för att varaktigt säkerställa systemens konfidentialitet, integritet och tillgänglighet; loggning kan bidra till det. Samtidigt får personuppgifter inte lagras längre än nödvändigt.

Fastställ därför en tidsfrist per loggtyp, skriv ner motiveringen och stäm av båda med ert dataskyddsombud. För en pågående utredning kan det vara nödvändigt att säkra loggar utöver den normala fristen. Det bör då likaså dokumenteras. Den här sidan är allmän information och ingen juridisk rådgivning; vid konkreta frågor hjälper dataskyddsombud och advokat. Hur ni utvärderar loggar efter ett angrepp visar Utvärdera webbserverloggar efter ett angrepp.

Hur hjälper PHP SOS konkret?

• Vi kontrollerar era befintliga loggar efter lösenord, tokens och andra data som inte hör hemma där.
• Vi ställer in PHP och applikationen så att fel loggas men inte visas.
• Vi inrättar en skyddad kopia av loggarna på ett separat system.
• Via säkerhetsövervakning utvärderar vi säkerhetsrelevanta poster löpande och rapporterar det som sticker ut på ett begripligt sätt.

Slutsats: Bra loggar är sparsamma i innehållet och generösa i skyddet. Den som i dag fastställer vad som loggas och vad som aldrig loggas har i skarpt läge användbara spår och inget extra dataläckage.

Vanliga frågor

Källor

• OWASP: Logging Cheat Sheet
• PHP-FIG: PSR-standarder
• PHP-manualen
• OWASP Top 10