PHP Object Injection via de functie unserialize() is een bekend risico. Er bestaat echter een variant van deze kwetsbaarheid die nog geraffineerder is en zich verschuilt in de manier waarop PHP omgaat met specifieke bestandsprotocollen (wrappers). Door gebruik te maken van de phar:// wrapper kunnen aanvallers onveilige deserialisatie triggeren via functies die normaal gesproken alleen bedoeld zijn om te controleren of een bestand bestaat (zoals file_exists()). Dit vormt een acuut gevaar voor WooCommerce-sites die gebruikmaken van verouderde media- of import-plug-ins.

Hoe de phar:// wrapper kwetsbaarheid werkt

Een PHAR-bestand (PHP Archive) is een archiefindeling (vergelijkbaar met een .zip-bestand) die metadata bevat. Het unieke aan de PHAR-architectuur is dat deze metadata in een geserialiseerd formaat is opgeslagen. Wanneer PHP een operatie uitvoert op een phar:// pad, wordt deze metadata automatisch gedeserialiseerd, zónder dat de functie unserialize() expliciet in de code hoeft te staan.

Als een WooCommerce-plug-in een gebruiker toestaat om een bestand te uploaden (bijvoorbeeld een profielfoto of een productafbeelding) en de plug-in controleert niet streng genoeg of het bestand stiekem een PHAR-archief is (vermomd als .jpg), kan de aanvaller het bestand op de server plaatsen.

Vervolgens zoekt de aanvaller naar een formulier dat een bestandspad accepteert en dit doorgeeft aan een standaard PHP-bestandsfunctie:

PHP
 
$user_path = $_POST['file_path'];
if (file_exists($user_path)) {
    // Logica...
}

De aanvaller manipuleert de invoer naar: phar://wp-content/uploads/avatar.jpg. Zodra file_exists() dit pad verwerkt, start PHP de deserialisatie van de metadata in de afbeelding, wat via een zogeheten POP chain leidt tot Remote Code Execution (RCE).

Impact op e-commerce systemen

Zodra RCE is bereikt via een PHAR-lek, heeft de hacker volledige controle over de WooCommerce-installatie. Hij kan direct backend-bestanden aanpassen, klantinformatie downloaden en database-tabellen leegmaken.

Hoe ontwikkelaars en beheerders zich beschermen

1. PHP Versie updaten

Sinds PHP 8.0 is de automatische deserialisatie van PHAR-metadata bij de meeste standaard bestandsfuncties uitgeschakeld, tenzij dit expliciet is geconfigureerd. Het draaien van uw WooCommerce-winkel op een moderne PHP-versie (PHP 8.2+) elimineert de primaire vector van deze aanval.

2. Strikte controle op bestandsextensies

Ontwikkelaars moeten ervoor zorgen dat uploads niet alleen worden gecontroleerd op het MIME-type, maar dat de werkelijke structuur van het bestand wordt gevalideerd. Gebruik functies zoals wp_check_filetype_and_ext() om te voorkomen dat PHAR-bestanden met een dubbele extensie (bijv. malicious.phar.jpg) door het filter glippen.

3. Voorkom rauwe pad-invoer

Geef gebruikers nooit de mogelijkheid om directe invloed uit te oefenen op bestandspaden die door het systeem worden ingeladen. Gebruik altijd vaste mappenstructuren en saniseer de invoer met basename().