J’ai récemment mis à niveau mon instance Discourse vers la dernière version Discourse/2.9.0.beta14 depuis Discourse/2.9.0.beta3.
L’événement webhook de Discourse ne fonctionne plus.
Voici la configuration :
URL de la charge utile : http://nom-serveur:port/rest : Il s’agit du service d’API REST interne que nous avons défini.
Lorsque j’essaie de sauvegarder cette valeur, j’obtiens l’erreur suivante :
« Une erreur s’est produite : L’URL de la charge utile ne peut pas être utilisée car elle résout une IP bloquée ou interne »
La même valeur pour l’URL de la charge utile : http://nom-serveur:port/rest fonctionnait correctement dans la version Discourse/2.9.0.beta3 de Discourse.
Quelque chose a-t-il été mis à jour dans la dernière version de Discourse, ou s’agit-il d’un bug ?
Pourriez-vous s’il vous plaît me faire savoir. Merci d’avance.
Cela ne semble pas correct. L’URL de la charge utile pour les webhooks peut effectivement être une ressource interne si Discourse est auto-hébergé. Je ne vois pas pourquoi vous voudriez empêcher la configuration d’URL ou d’adresses qui se résolvent en interne pour le traitement des webhooks. Il semble y avoir eu un changement pour empêcher les URL de sites Web invalides/mauvaises sur les profils utilisateur. Ce changement a-t-il affecté la validation de l’URL de la charge utile du webhook ?
Parce que cela peut aussi être un problème de sécurité où un administrateur Discourse pourrait utiliser des webhooks pour découvrir ou attaquer des ressources internes sur un réseau qui n’est pas le leur ?
Oui, déplacé ceci vers Feature, cela peut être utilisé pour extraire des informations sur un réseau interne. Il y a quelques réglages pour ajuster le comportement sur une instance spécifique.
Notre instance auto-hébergée est également affectée par cela. Nous aimerions héberger le service qui reçoit le webhook uniquement sur le réseau Docker interne ; il n’est pas nécessaire qu’il soit accessible de l’extérieur.
Existe-t-il un moyen d’autoriser les webhooks internes ?
Si je comprends bien le problème, les webhooks internes ne sont pas autorisés afin qu’un administrateur Discourse, qui n’a pas les droits d’administrateur serveur, ne puisse pas espionner les internes du réseau. Ce n’est cependant pas un problème sur notre instance auto-hébergée ; nos administrateurs Discourse connaîtraient de toute façon notre structure interne.
Je suggérerais un paramètre dans la configuration app.yml pour autoriser les webhooks internes, ou pour fournir une liste blanche de domaines/IP internes. De cette façon, l’administrateur serveur (pas l’administrateur Discourse) garde le contrôle de qui peut utiliser les webhooks pour le réseau interne.
J’ai trouvé un paramètre qui permet de débloquer des hôtes internes spécifiques et qui est respecté par le mécanisme de protection SSRF qui bloque les WebHooks en premier lieu :
Utilisez le paramètre allowed_internal_hosts pour spécifier les noms d’hôtes internes autorisés dans votre webhook.