Hoewel JSON tegenwoordig de overhand heeft in moderne webapplicaties, blijft XML een veelgebruikt formaat voor gegevensuitwisseling, met name bij oudere enterprise-systemen, ERP-koppelingen en specifieke import/export-plug-ins voor WooCommerce. Wanneer een WordPress-plug-in XML-bestanden van gebruikers accepteert en verwerkt zonder de XML-parser correct te configureren, ontstaat er een risico op een XML External Entity (XXE) injectie. Deze kwetsbaarheid kan door aanvallers worden misbruikt om lokale bestanden te lezen, interne poorten te scannen of zelfs Denial of Service (DoS) aanvallen te veroorzaken.

Hoe XXE-injectie werkt

XML staat het gebruik toe van zogenaamde 'external entities' (externe entiteiten). Dit zijn variabelen binnen een XML-document die hun waarde ophalen uit een externe bron, zoals een lokaal bestand of een URL. Een kwaadaardig XML-bestand dat naar een kwetsbare WooCommerce-importeur wordt geüpload, kan er als volgt uitzien:

XML
 
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [  
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<products>
  <product>
    <name>&xxe;</name>
    <price>19.99</price>
  </product>
</products>

Wanneer de onveilige PHP-parser (zoals een oudere configuratie van simplexml_load_string) dit bestand verwerkt, vervangt hij de entiteit &xxe; door de inhoud van het /etc/passwd bestand. Als de plug-in vervolgens de productnaam op het scherm toont of in een logboek opslaat, kan de aanvaller de gevoelige systeeminformatie direct inzien. In een WordPress-omgeving is het primaire doelwit vaak het wp-config.php bestand, om zo de database-inloggegevens te bemachtigen.

Impact op WooCommerce-omgevingen

Binnen WooCommerce manifesteer XXE zich meestal in add-ons die XML-feeds van leveranciers verwerken, of in plug-ins die B2B-bestellingen via XML-bestanden automatiseren.

  • Exfiltratie van gegevens: Naast systeembestanden kunnen aanvallers configuratiebestanden van payment gateways uitlezen.

  • Server-Side Request Forgery (SSRF): Een XXE-lek kan worden gebruikt om de server verzoeken te laten sturen naar interne netwerkbronnen die niet vanaf het internet toegankelijk zijn (bijvoorbeeld cloud-metadata endpoints zoals 169.254.169.254).

Preventie voor ontwikkelaars

Sinds PHP 8.0 is de onderliggende XML-parser (libxml) standaard beter beveiligd tegen het laden van externe entiteiten. Ontwikkelaars die echter nog ondersteuning bieden voor oudere PHP-omgevingen, of die handmatig parsers configureren, moeten expliciet externe entiteiten uitschakelen.

De veiligste manier om XML in PHP te verwerken is door gebruik te maken van de functie libxml_disable_entity_loader() (voor PHP-versies vóór 8.0) of door de PHP-opties voor DOMDocument correct in te stellen:

PHP
 
$document = new DOMDocument();
// Schakel het laden van externe entiteiten expliciet uit
libxml_use_internal_errors(true);
$document->loadXML($xml_data, LIBXML_NONET | LIBXML_DTDLOAD);

Het gebruik van LIBXML_NONET zorgt ervoor dat de parser geen netwerkverbindingen opzet om externe DTD's of entiteiten op te halen.

Advies voor webshopeigenaren

  • PHP 8.x afdwingen: Zorg ervoor dat uw webshop draait op een moderne PHP-versie (PHP 8.1 of hoger), waar de standaardinstellingen voor XML-verwerking inherent veilig zijn.

  • Beperk importrechten: Sta alleen vertrouwde beheerders toe om XML- of CSV-bestanden te uploaden voor productupdates. Schakel product-uploads door klanten (bijvoorbeeld voor gepersonaliseerde ontwerpen) strikt over naar veilige afbeeldingsformaten.