SQL-injectie (SQLi) blijft een van de meest hardnekkige en gevaarlijke kwetsbaarheden binnen het WordPress-ecosysteem. Hoewel de WordPress-core doorgaans zeer goed beveiligd is tegen dit soort aanvallen, vormen plug-ins en extensies van derden – met name voor het complexe WooCommerce-platform – een aanzienlijk risico. Wanneer een plug-in er niet in slaagt om gebruikersinvoer correct te filteren of te sanctioneren voordat deze aan een database-query wordt toegevoegd, krijgt een kwaadwillende de kans om directe SQL-commando's uit te voeren. Dit kan leiden doortot totale overname van de website, diefstal van gevoelige klantgegevens en het manipuleren van transacties.
Het mechanisme achter SQLi in WordPress
De database van WordPress (wp_posts, wp_users, wp_usermeta, etc.) bevat alle vitale informatie van een website. Wanneer een ontwikkelaar een aangepaste database-query schrijft met behulp van de $wpdb klasse, is het cruciaal om variabelen op een veilige manier te introduceren. Een klassieke fout is het direct aaneenschakelen (concatenatie) van variabelen uit $_GET of $_POST arrays in de SQL-instructie.
Stel dat een WooCommerce-plug-in voor het filteren van producten op basis van een aangepaste ID de volgende code gebruikt:
$product_id = $_GET['prod_id'];
$results = $wpdb->get_results("SELECT * FROM wp_posts WHERE ID = " . $product_id);
Als een aanvaller in plaats van een numeriek ID de waarde 1 OR 1=1 meestuurt, verandert de query logica fundamenteel. De database zal alle rijen teruggeven. In complexere scenario's, zoals Blind SQL Injection of Union-based SQL Injection, kunnen aanvallers tabellen uitlezen, admin-wachtwoordhashes extraheren of zelfs nieuwe administrator-accounts rechtstreeks in de wp_users tabel injecteren.
De impact op WooCommerce-webshops
Voor een e-commerceplatform zijn de gevolgen van SQL-injectie catastrofaal. WooCommerce-winkels verwerken niet alleen productgegevens, maar slaan ook klantinformatie, bestelgeschiedenis, NAW-gegevens en soms (versleutelde) tokens voor betalingen op.
-
Datalekken en AVG/GDPR: Een succesvolle SQLi-aanval stelt hackers in staat om de volledige klantendatabase te exporteren. Dit resulteert in zware boetes onder de privacywetgeving en onherstelbare imagoschade.
-
Prijsmanipulatie: Aanvallers kunnen productprijzen in de database aanpassen naar nul of een fractie van de werkelijke waarde, waardoor ze dure producten gratis kunnen bestellen voordat de winkelier het merkt.
-
Malware-injectie: SQL-injecties kunnen worden gebruikt om kwaadaardige JavaScript-code in de database te plaatsen (Stored XSS), die vervolgens wordt uitgevoerd in de browser van elke bezoeker, bijvoorbeeld om creditcardgegevens te skimmen.
Preventie en mitigatie voor ontwikkelaars
Het voorkomen van SQL-injectie in WordPress is relatief eenvoudig als ontwikkelaars zich houden aan de officiële coderingsstandaarden. De belangrijkste verdedigingslinie is het gebruik van de methode $wpdb->prepare().
De $wpdb->prepare() methode werkt vergelijkbaar met prepared statements in standaard PHP (PDO). Het zorgt ervoor dat de invoer strikt wordt behandeld als een parameter en nooit als uitvoerbare code. De eerder genoemde onveilige query moet als volgt worden herschreven:
$product_id = intval($_GET['prod_id']);
$query = $wpdb->prepare("SELECT * FROM wp_posts WHERE ID = %d", $product_id);
$results = $wpdb->get_results($query);
In dit voorbeeld zorgt %d ervoor dat de waarde als een integer wordt behandeld. Voor strings wordt %s gebruikt, en voor floats %f. Daarnaast is het typecasting van variabelen (zoals (int) of intval()) een uitstekende aanvullende gewoonte.