Wanneer u WordPress en plug-ins installeert, worden er honderden PHP-bestanden op uw server geplaatst. Elk van deze bestanden is in principe rechtstreeks via de browser aan te roepen als een aanvaller het exacte pad weet, bijvoorbeeld https://uwshop.nl/wp-content/plugins/een-extensie/includes/process-data.php. Als een ontwikkelaar er bij het bouwen van de plug-in vanuit is gegaan dat dit bestand alleen via de WordPress-core wordt ingeladen, en er geen controle is ingebouwd voor directe toegang, kan dit leiden tot onverwachte fouten, informatie-lekkage of het ongeautoriseerd uitvoeren van functies.

Waarom Direct File Access gevaarlijk is

Wanneer een PHP-bestand rechtstreeks wordt aangeroepen, omzeilt het de normale initialisatieketen van WordPress. Dit betekent dat vitale functies, rollencontroles en beveiligingsmechanismen (zoals nonces) mogelijk niet zijn geladen.

Als het bestand variabelen probeert te gebruiken die normaal gesproken door de WordPress-core worden gedefinieerd (zoals $wpdb), kan dit leiden tot fatale PHP-fouten die pad-informatie blootleggen op het scherm (Full Path Disclosure). In ergere gevallen bevat het bestand standalone logica – zoals het opschonen van een tijdelijke map of het exporteren van logbestanden – die een aanvaller nu herhaaldelijk kan triggeren om de site te ontregelen.

Hoe ontwikkelaars directe toegang blokkeren

De oplossing voor dit probleem is een standaardpraktijk binnen de WordPress-ontwikkeling. Elk PHP-bestand dat niet bedoeld is om rechtstreeks door de browser te worden uitgevoerd (vrijwel alle bestanden behalve de hoofd-index.php en specifieke API-handlers), moet beginnen met een controle of de WordPress-omgeving actief is.

Dit wordt gedaan door te controleren of de constante ABSPATH (het absolute pad naar de WordPress-installatie) is gedefinieerd. Als dit niet het geval is, betekent dit dat het bestand rechtstreeks is aangeroepen, en wordt de uitvoering onmiddellijk gestopt met die of exit.

PHP
 
<?php
// Blokkeer directe toegang tot het bestand
if (!defined('ABSPATH')) {
    exit; // Of: die('Directe toegang niet toegestaan.');
}

// Rest van de plug-in code...

Door deze eenvoudige controle aan de absolute top van elk PHP-bestand te plaatsen, is het bestand immuun voor directe exploitatie via de browser.

Wat kunnen webshopeigenaren doen?

  • Blokkeer PHP-uitvoering in specifieke mappen: Er zijn mappen binnen WordPress waar nooit PHP-bestanden rechtstreeks door de browser uitgevoerd hoeven te worden, zoals de mappen wp-content/uploads/ en wp-includes/. U kunt via het .htaccess bestand of de Nginx-configuratie de uitvoering van PHP in deze mappen volledig blokkeren.

  • Gebruik een Security Scanner: Goede beveiligingsplug-ins scannen uw plug-in-mappen en waarschuwen u als er bestanden aanwezig zijn die direct toegankelijk zijn en potentieel gevoelige foutmeldingen genereren.