3.5 KiB
OBS-02 — Destinations webhook sans politique réseau démontrée
Mise à jour du 17 septembre 2026 : voir le compte rendu de correction. Le texte ci-dessous conserve le constat avant cette passe. Deux tests du pipe réel confirment le rejet actuel des URL en création et modification ; aucune voie SSRF complète n’est établie.
Statut : hypothèse d'exploitation non confirmée ; chemin de configuration actuellement contrarié par la validation des DTO. Aucun SSRF exploitable depuis l'API n'est affirmé. SSRF signifie qu'un utilisateur fait émettre au serveur une requête vers une destination qu'il ne devrait pas pouvoir joindre.
Destination sensible
WebhookService appelle httpService.post(webhook.url, payload, {headers, timeout:10000}), ligne 209 du fichier courant. La signature HMAC sert à authentifier le message auprès du destinataire ; elle ne garantit pas que ce destinataire est autorisé. Le délai de dix secondes borne une tentative mais n'interdit pas une adresse interne. Le chemin inspecté n'applique pas de politique d'adresse IP ou de destination avant l'envoi.
Une URL contrôlée qui atteindrait ce stockage puis un événement déclencheur pourrait ainsi faire contacter une destination interne accessible au backend. Il reste à vérifier les résolutions DNS, redirections et contraintes réseau du déploiement ; aucun accès à une adresse interne ou à un service de métadonnées n'a été testé.
Pourquoi ce n'est pas un SSRF confirmé
Les classes CreateWebhookDto et UpdateWebhookDto, dans webhooks.controller.ts lignes 27–39, déclarent des propriétés TypeScript sans décorateurs de validation. main.ts active I18nValidationPipe avec whitelist:true et forbidNonWhitelisted:true. Dans ce chemin, les champs non déclarés à la validation sont rejetés, ce qui empêche d'assumer qu'un MANAGER peut enregistrer librement une URL depuis le contrôleur.
Les routes exigent ADMIN/MANAGER. Le fait qu'un service possède un paramètre URL ne prouve pas qu'un attaquant peut le renseigner dans la version courante. L'existence d'anciens webhooks en base, d'un import ou d'une autre voie d'écriture reste inconnue. Le rapport initial a donc écarté la présentation d'une exploitation confirmée par enregistrement API.
Risque lors d'un changement futur
Ajouter les décorateurs manquants aux DTO peut rendre la création fonctionnelle et ouvrir simultanément le chemin vers l'envoi HTTP. Il faut alors analyser ensemble validation fonctionnelle et politique de destinations ; une correction de formulaire isolée peut retirer l'obstacle actuel sans résoudre le risque réseau.
Vérifications à effectuer
- Tester la création et la modification via une application locale possédant le véritable pipe global ; ne pas appeler directement le service en prétendant avoir validé la route HTTP.
- Inventorier les autres écritures du repository et les données préexistantes sans publier les URL sensibles.
- Si une voie d'entrée est confirmée, vérifier avec des serveurs locaux les restrictions d'adresses, la résolution DNS et chaque redirection avant d'attribuer une gravité.
- Préserver un endpoint public autorisé comme contrôle positif.
Aucune requête réseau nouvelle ni correction n'a été effectuée pour cette fiche.
Sources : contrôleur, service, validation globale.