De WordPress debug log beveiligen

Wanneer WordPress-debugging is ingeschakeld, worden fouten en waarschuwingen weggeschreven naar een logbestand op /wp-content/debug.log. Dit is ongelooflijk handig tijdens ontwikkeling. Op een productiesite is een openbaar toegankelijk debug-log echter een ernstig beveiligingsrisico. Iedereen die de URL kent, kan het lezen, en het bevat vaak veel gevoeligere informatie dan de meeste site-eigenaren beseffen.

Wat de debug log bevat

Het bestand debug.log is niet alleen een lijst met PHP-waarschuwingen. Afhankelijk van de configuratie van uw site en de plugins die u gebruikt, kan het het volgende bevatten:

• PHP-fouten en -waarschuwingen: Deze bevatten bestandspaden, regelnummers en functienamen. Een aanvaller kan deze informatie gebruiken om de directorystructuur van uw server in kaart te brengen en kwetsbare code te identificeren.
• Databasequeryfouten: Mislukte query's bevatten soms tabelnamen, kolomnamen en zelfs fragmenten van de gegevens die worden opgevraagd. Dit geeft aanvallers inzicht in uw databaseschema.
• Plugin- en themafouten met stack traces: Stack traces onthullen welke plugins u gebruikt, hun versies en hoe ze interacteren. Dit is waardevol voor het plannen van gerichte aanvallen tegen bekende plugin-kwetsbaarheden.
• API-sleutels en inloggegevens: Slecht geschreven plugins loggen soms API-responsen of verbindingsfouten die authenticatietokens, API-sleutels of zelfs wachtwoorden in platte tekst bevatten.
• Gebruikersgegevens en e-mailadressen: Fouten gerelateerd aan gebruikersregistratie, formulierinzendingen of e-mailverzending kunnen persoonlijke gegevens bevatten zoals namen, e-mailadressen en formulierinvoer.
• Bestandssysteempaden: Elke PHP-fout bevat het volledige serverpad naar het bestand waarin de fout optrad. Dit onthult uw hosting-directorystructuur, gebruikersnaam en soms uw hostingprovider.

Waarom de debug log openbaar toegankelijk is

Standaard slaat WordPress debug.log op in de directory wp-content. Deze directory wordt door uw webserver bediend net als elke andere map in uw WordPress-installatie. Tenzij u specifiek toegang heeft geblokkeerd, kan iedereen https://uwsite.nl/wp-content/debug.log in een browser typen en het bestand lezen.

Veel hostingproviders blokkeren dit pad standaard niet. En omdat het bestand in de loop van de tijd groeit zonder automatische rotatie, kan het maanden of zelfs jaren aan gevoelige foutgegevens verzamelen.

Hoe aanvallers debug logs vinden

Geautomatiseerde scanners controleren routinematig op /wp-content/debug.log bij elke WordPress-site die ze tegenkomen. Het is een van de eerste paden die beveiligingsscantools testen. Sommige aanvallers controleren ook op veelvoorkomende variaties:

• /wp-content/debug.log (standaardlocatie)
• /debug.log (soms verkeerd geconfigureerd)
• /wp-content/uploads/debug.log (een andere veelvoorkomende misconfiguratie)
• /error_log of /error.log (generieke namen voor foutlogs)

Deze scans zijn goedkoop, snel en volledig geautomatiseerd. Als uw debug log toegankelijk is, wordt deze gevonden.

Toegang blokkeren met .htaccess (Apache)

Als uw server op Apache draait, voeg deze regel toe aan het .htaccess-bestand in uw wp-content-directory:

    Order allow,deny
    Deny from all

Dit vertelt Apache om alle HTTP-verzoeken voor het bestand debug.log te weigeren. Het bestand bestaat nog steeds op schijf en PHP kan er nog steeds naar schrijven, maar niemand kan het via een browser downloaden. Als u uit voorzorg alle logbestanden wilt blokkeren, kunt u een bredere regel gebruiken:

    Order allow,deny
    Deny from all

Toegang blokkeren met Nginx

Voor Nginx-servers, voeg dit locatieblok toe aan uw serverconfiguratie:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Een 404 retourneren in plaats van een 403 is een bewuste keuze. Een 403 (Forbidden)-respons vertelt een aanvaller dat het bestand bestaat maar beschermd is. Een 404 (Not Found) verraadt niets. Na het toevoegen van deze regel, herlaad de Nginx-configuratie met sudo nginx -s reload.

Verplaats het logbestand buiten de webroot

De veiligste benadering is om de debug log op te slaan in een directory die uw webserver helemaal niet kan serveren. Stel in uw wp-config.php de constante WP_DEBUG_LOG in op een absoluut pad buiten uw webroot:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/uwgebruiker/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

De directory /home/uwgebruiker/logs/ moet bestaan en beschrijfbaar zijn voor het webserverproces. WP_DEBUG_DISPLAY instellen op false is even belangrijk: het voorkomt dat PHP-fouten direct op uw pagina's worden getoond, waar bezoekers (en aanvallers) ze zouden kunnen zien.

Schakel debugmodus uit op productiesites

Op een live productiesite zou debugging bijna altijd uitgeschakeld moeten zijn. Er is zelden een goede reden om het permanent ingeschakeld te laten. Stel deze waarden in wp-config.php in:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Als u een probleem moet debuggen op productie, schakel debugmodus dan tijdelijk in, reproduceer het probleem, controleer de log en schakel het direct daarna weer uit. Laat debugging nooit "voor het geval dat" ingeschakeld. Het risico is het gemak niet waard.

Monitor de bestandsgrootte van de debug log

Als u debugging ingeschakeld houdt op een staging- of ontwikkelsite, monitor dan de grootte van de debug log. Zonder logrotatie kan deze groeien tot honderden megabytes en uiteindelijk uw schijf vullen. Overweeg een cronjob in te stellen om deze te roteren of in te korten:

# Rotate debug.log weekly, keep 4 backups
# Add to /etc/logrotate.d/wp-debug
/home/uwgebruiker/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Wat te doen als gevoelige gegevens al zijn blootgesteld

Als uw debug log openbaar toegankelijk was en gevoelige informatie bevatte, neem dan onmiddellijk deze stappen:

• Verwijder het debug log-bestand: Verwijder het direct van de server.
• Roteer alle API-sleutels en inloggegevens: Elke API-sleutel, wachtwoord of token die in de log verscheen, moet als gecompromitteerd worden beschouwd. Genereer ze opnieuw.
• Wijzig databasewachtwoorden: Als databaseverbindingsfouten zijn gelogd, kunnen de inloggegevens zijn blootgesteld.
• Controleer op ongeautoriseerde toegang: Bekijk de toegangslogs van uw server op verzoeken voor debug.log. Als iemand het heeft gedownload, beoordeel dan welke informatie hij heeft verkregen.
• Stel getroffen gebruikers op de hoogte: Als persoonlijke gegevens (e-mails, namen, formulierinzendingen) zijn gelogd, heeft u mogelijk een GDPR- of privacyverplichting om getroffen personen te informeren.

Verifieer met InspectWP

InspectWP controleert of /wp-content/debug.log openbaar toegankelijk is op uw site. Voer na het beveiligen van het bestand (toegang blokkeren, verplaatsen of debugmodus uitschakelen) een nieuwe InspectWP-scan uit. De beveiligingssectie van het rapport bevestigt of het bestand nog bereikbaar is. Als de waarschuwing aanhoudt, wis dan eventuele server-side caches en verifieer dat uw .htaccess- of Nginx-regels worden toegepast op de juiste directory.