Recientemente he actualizado mi instancia de Discourse a la última versión Discourse/2.9.0.beta14 desde Discourse/2.9.0.beta3.
El evento webhook de Discourse ha dejado de funcionar ahora.
Esta es la configuración
URL de carga útil: http://nombre-servidor:puerto/rest: Este es el servicio interno de API REST que hemos definido.
Cuando intento guardar este valor, me da el siguiente error:
“Ocurrió un error: La URL de carga útil no se puede utilizar porque resuelve a una IP bloqueada o interna”
El mismo valor para la URL de carga útil: http://nombre-servidor:puerto/rest solía funcionar bien en la
versión de Discourse Discourse/2.9.0.beta3.
¿Hay algo que se haya actualizado en la última versión de Discourse, o es un error?
Esto no suena bien. La URL de carga útil para webhooks puede ser un recurso interno si Discourse está autoalojado. No estoy seguro de por qué querrías dejar de poder configurar URL o direcciones que se resuelven internamente para procesar webhooks. Parece que ha habido un cambio para evitar URL de sitios web no válidos/malos en los perfiles de usuario. ¿Se ha introducido ese cambio en la validación de la URL de carga útil del webhook?
¿Porque también puede ser un problema de seguridad donde un administrador de Discourse podría usar webhooks para descubrir o atacar recursos internos en una red que no es suya?
Sí, moví esto a Feature, se puede usar para obtener información sobre una red interna. Hay algunas opciones para ajustar el comportamiento en una instancia específica.
Nuestra instancia autoalojada también se ve afectada por esto. Nos gustaría alojar el servicio que recibe el webhook solo en la red interna de Docker; no es necesario que sea accesible desde el exterior.
¿Hay alguna forma de permitir webhooks internos?
Si entiendo el problema correctamente, los webhooks internos no están permitidos para que un administrador de Discourse, que no tiene los permisos de administrador del servidor, no pueda espiar los internos de la red. Sin embargo, este no es un problema en nuestra instancia autoalojada; nuestros administradores de Discourse ya conocerían nuestra estructura interna.
Sugeriría una configuración en el archivo de configuración app.yml para permitir webhooks internos, o proporcionar una lista blanca de dominios/IP internas. De esta manera, el administrador del servidor (no el administrador de Discourse) mantiene el control sobre quién puede usar webhooks para la red interna.
Encontré una configuración que permite desbloquear hosts internos específicos y es respetada por el mecanismo de Protección SSRF que está causando el bloqueo de los WebHooks en primer lugar:
Use la configuración allowed_internal_hosts para especificar qué nombres de host internos están permitidos en su webhook.