Webhook et URL interne : quand le CMS devient un relais
Un champ « URL de notification » qui pointe vers l'interne, ou vers un tiers que vous n'avez pas choisi, fait du CMS un relais. Après incident, auditez webhooks boutique et formulaires. On dresse la liste, on révoque, on ne « teste pas le réseau » au hasard.
Un champ « URL de notification » pointe vers l'interne ou vers un tiers malveillant. Auditez les webhooks boutique et formulaires après incident.
Ce qu'un webhook a à faire — et plus
Prévenir Stripe, un transporteur, un ERP, un outil de facturation : le CMS envoie un message vers une URL que vous avez déclarée. Légitime. Le même mécanisme, réglé vers un inconnu, exfiltre des commandes. Réglé sans discernement, il peut aussi pousser le serveur à interroger des adresses qu'il n'aurait jamais dû joindre (réseau interne, services de métadonnées). On appelle ça un relais. On n'en fait pas un tutoriel.
Après un incident, la question n'est pas « comment frapper le réseau ». C'est : quelles URLs sont encore enregistrées, qui les a posées, les secrets sont-ils encore bons.
C'est le cousin boutique de GTM : une origine hors « fichier PHP à la racine », assez pour pourrir un checkout propre sur le disque.
Après un piratage : pourquoi les relire
Un attaquant admin ou une clé REST trop large ajoute un webhook « commande créée → son URL ». Les fichiers sont clean. Les commandes partent ailleurs. WooCommerce / HPOS, clés REST, webhooks paiement.
Un champ « URL de callback » dans un formulaire ou un module de notification SMS : même famille. Relisez après, pas « si on a le temps ».
Un prestataire oublié a encore un endpoint. Fin de mission. Révoquez comme un utilisateur.
Où les lister, CMS par CMS
WooCommerce : Réglages → Avancé → Webhooks. PrestaShop : modules, webservice, notifications de commande. Magento : intégrations. WordPress : plugins « webhook », « Zapier », « Make », Contact Form « webhooks ». Stripe / PayPal : le Dashboard, pas seulement le CMS.
Notez : événement, URL, date, statut. Photographiez avant de supprimer. Le constat aime les dates.
Les crons qui « appellent une URL » sont des webhooks pauvres. Relisez le cron système aussi. Cron.
- CMS : liste native des webhooks.
- PSP : endpoints dans le Dashboard.
- Automatisation (Zapier, Make, n8n) : scénarios actifs.
Destinations : les vôtres, les autres, l'interne
Les vôtres : ERP, outil nommé, HTTPS, domaine que vous assumez. Les autres : un hostname que personne ne revendique, un IP, un raccourcisseur. L'interne : adresses de réseau privé, hôtes de métadonnées cloud, localhost. Ces dernières n'ont rien à faire dans un champ de boutique. On les retire. On ne « vérifie pas si ça répond » depuis la prod pour s'amuser.
Si vous trouvez de l'interne, notez-le au constat : le CMS a pu être utilisé comme relais. C'est un fait d'architecture, pas une preuve d'exfiltration à elle seule. Le reste de l'analyse (journaux, volumes) dit si quelque chose est sorti.
Un `.env` exposé contient parfois déjà ces URLs et leurs secrets. Rotation dans la même passe.
Ce que l'audit n'est pas
Ce n'est pas scanner vos plages internes. Ce n'est pas coller des URLs d'épreuve dans le champ pour « voir ». Ce n'est pas republier un PoC. C'est un inventaire de configuration, comme on inventorie les utilisateurs admin.
Un devis qui promet un « pentest SSRF » dans le forfait nettoyage mélange deux métiers. Nous listons et nous fermons. Un test d'intrusion se commande à part, avec des règles.
Les lecteurs de cet article sont des gens qui ont un site pirate, pas un lab. L'ordre reste : constater, copier, couper les relais inconnus, tourner les secrets.
Clés, signatures, et le secret qui fuit
Un webhook sans signature, ou avec un secret collé dans un ticket, se rejoue. Après incident, régénérez les secrets, préférez les signatures natives (Stripe, Woo). Révoquez les clés qui permettent d'ajouter des webhooks.
Les application passwords et les clés Magento / Presta webservice sont le même tiroir. Application passwords, webservice Presta.
Si le secret a vécu dans le Git public, considérez-le lu. `.git` en ligne.
Formulaires, Zapier, et les « automatisations »
Un formulaire qui poste vers une URL « slack webhook » inconnue : mêmes questions. Coupez, tournez le webhook Slack s'il était à vous (les URLs Slack se régénèrent).
Zapier / Make : un scénario ajouté, un compte connecté. Déconnectez les apps, revoyez les Zaps. C'est hors FTP, encore.
Les pixels et replays sont une exfiltration navigateur, pas un webhook serveur. Autre article, même semaine de revue. Hotjar.
Clôturer sans casser la logistique
Ne videz pas tous les webhooks d'un clic un vendredi de soldes sans prévenir la logistique. Isolez les inconnus, gardez ceux que le transitaire nomme, documentez. Un tunnel fermé volontairement, c'est une décision. Un ERP muet par accident, c'est un second incident.
Ensuite : moins de gens qui peuvent créer un webhook, 2FA, revue dans la surveillance (nouveau endpoint = alerte).
Déclarer : dites si Woo / Presta / Stripe. On ouvrira ces listes en même temps que les fichiers. Un forfait « vitrine » qui ignore les webhooks est trop étroit pour une boutique.