WooCommerce pilonné par de fausses commandes

Un bot qui teste des cartes bancaires

J'ai un client avec une petite boutique e-commerce de niche tournant sur WooCommerce. C'est une installation WordPress auto-hébergée, avec juste assez de personnalisations pour répondre à des besoins très précis. Ces derniers temps, on voyait un filet régulier de commandes échouées, environ une toutes les 10 minutes, toutes avec le même motif. Pas besoin d'être un génie pour soupçonner du test de cartes par bot.

On a essayé reCaptcha v3. C'était lourd, mais ça a tenu un temps. Puis les attaquants ont changé de tactique et sont passés à travers. Il s'avère qu'on avait laissé filer une grande porte dérobée.

Plusieurs API, qui savait ?

J'ai l'habitude des choses qui flottent dans l'écosystème WordPress, mais voici la torsion : WooCommerce a introduit une autre API, la Store API, principalement pour soutenir leur panier et leur checkout en blocs. C'est documenté côté développeurs, mais il n'y a pas eu d'« annonce » bien visible sur leur blog principal, et franchement je ne suis pas ces évolutions de près, car WordPress n'est vraiment pas ma tasse de thé.

Bref, la Store API est conçue pour une expérience headless et des front-ends modernes. Elle autorise des interactions au niveau invité. Ce n'est pas nécessairement une « vulnérabilité » au sens classique, mais c'est un choix de conception mûr pour l'abus par des bots, et certaines garanties évidentes (par exemple la possibilité de désactiver l'API ou des parties de l'API quand on n'utilise pas le système de blocs) n'ont pas été introduites. Je trouve cela assez problématique.

Mettre le bot dehors

Ma première tentative a été un correctif rapide : utiliser woocommerce_checkout_process pour filtrer les adresses e-mail suspectes. Sauf que la Store API ne joue pas selon les mêmes règles que le flux de checkout traditionnel.

On n'utilisait même pas cette nouvelle API, mais elle existait, prête à être exploitée. Alors je suis passé en mode terre brûlée :

add_action( 'rest_api_init', function () {
    if ( strpos( $_SERVER['REQUEST_URI'], '/wc/store' ) !== false ) {
        wp_die(
            json_encode( [ 'error' => 'Store API is disabled on this site.' ] ),
            'Store API Disabled',
            [ 'response' => 403, 'content-type' => 'application/json' ]
        );
    }
});

Adieu, Store API. Pas une solution gracieuse, mais on va de toute façon migrer.

Causes profondes

Ce projet n'a presque aucun budget de maintenance. Maintenir WooCommerce, le thème et les plugins à jour relevait déjà de l'exploit. On avait envisagé Shopify, mais il fallait des fonctions sur mesure qui n'étaient pas faisables à l'époque sans dépenser plus que ce que l'on avait.

Aujourd'hui, la situation a changé. On envisage de passer à une plateforme hébergée qui limite notre flexibilité mais offre une meilleure sécurité par défaut. Ironie : la Store API a probablement vu le jour pour faciliter la vie des installations headless complexes, le genre de constructions à gros budget qui peuvent se permettre de durcir leurs pipelines. Pour une toute petite boutique au budget serré, ce genre de « progrès » n'est pas utile.