In de cybersecurity-toplijsten (zoals de OWASP Top 10) staat 'Broken Access Control' (gebroken toegangscontrole) momenteel op de allereerste plaats. Binnen het WordPress- en WooCommerce-ecosysteem is dit type kwetsbaarheid een van de meest voorkomende redenen waarom webshops ongewild gevoelige data blootstellen. Gebroken toegangscontrole houdt in dat een website er niet in slaagt om restricties af te dwingen op wat geautoriseerde of ongeautoriseerde gebruikers kunnen doen. In een WooCommerce-omgeving kan dit betekenen dat een gewone klant toegang krijgt doortot de bestellingen van andere klanten, of erger nog, admin-functies kan uitvoeren.

De architectuur van rechten in WordPress

WordPress maakt gebruik van een systeem van rollen en capaciteiten (Roles and Capabilities). Standaard kent WordPress rollen zoals Administrator, Editor, Author, Contributor en Subscriber. WooCommerce voegt daar rollen aan toe zoals Customer (Klant) en Shop Manager (Winkelmanager).

Elke actie die een gebruiker uitvoert, moet worden gecontroleerd aan de hand van deze capaciteiten. Een veelgemaakte fout bij het ontwikkelen van plug-ins is de aanname dat een actie veilig is, simpelweg omdat de link naar die actie verborgen is in de gebruikersinterface. Hackers scannen echter direct naar de onderliggende API-endpoints, AJAX-handlers of URL-parameters om te kijken of de server de rechten daadwerkelijk afdwingt.

Hoe Broken Access Control zich manifesteert in WooCommerce

Er zijn verschillende manieren waarop toegangscontrole kan falen binnen een e-commerceomgeving:

  1. Insecure Direct Object References (IDOR): Dit gebeurt wanneer een plug-in een directe verwijzing naar een database-object (zoals een bestellingsnummer) gebruikt zonder te controleren of de huidige gebruiker de eigenaar is. Bijvoorbeeld: de URL vulnerable-shop.com/view-order/?order_id=1024 laat de factuur van klant A zien. Als klant A de parameter handmatig verandert naar order_id=1025 en de factuur van klant B kan inzien, is er sprake van een IDOR-kwetsbaarheid.

  2. Onbeschermde AJAX-acties (wp_ajax_ en wp_ajax_nopriv_): WordPress maakt intensief gebruik van AJAX voor dynamische functies (zoals het toevoegen van producten aan de winkelwagen zonder de pagina te herladen). Ontwikkelaars registreren acties met wp_ajax_nopriv_action_name voor niet-ingelogde gebruikers. Als een ontwikkelaar per ongeluk een administratieve functie (zoals het verwijderen van een product of het exporteren van gebruikers) registreert onder de nopriv hook, kan iedereen deze functie aanroepen.

  3. Onvoldoende controle op REST API-endpoints: WooCommerce biedt een krachtige REST API. Als aangepaste extensies hun eigen endpoints registreren via register_rest_route(), moeten ze verplicht een permission_callback parameter definiëren. Als deze callback ontbreekt of altijd true retourneert, ligt het endpoint open voor de hele wereld.

Technische remedies voor ontwikkelaars

Het repareren van gebroken toegangscontrole vereist dat er bij elke interactie tussen de client en de server een expliciete controle plaatsvindt.

  • Gebruik current_user_can(): Voordat er gevoelige data wordt getoond of een actie wordt uitgevoerd, moet WordPress controleren of de gebruiker de juiste capaciteit heeft. Voor WooCommerce-beheerfuncties is de capaciteit manage_woocommerce de standaardnorm.

PHP
 
add_action( 'wp_ajax_delete_custom_coupon', 'my_delete_coupon_function' );
function my_delete_coupon_function() {
    if ( ! current_user_can( 'manage_woocommerce' ) ) {
        wp_send_json_error( array( 'message' => 'Niet geautoriseerd!' ), 403 );
    }
    // Code om de kortingscode te verwijderen...
}

  • Eigendom valideren: Bij het tonen van klantspecifieke data moet de code controleren of het object gekoppeld is aan de ID van de momenteel ingelogde gebruiker:

PHP
 
$order = wc_get_order( $order_id );
if ( $order && $order->get_customer_id() !== get_current_user_id() ) {
    wp_die( 'Toegang geweigerd.' );
}