Recentemente atualizei minha instância do Discourse para a versão mais recente Discourse/2.9.0.beta14 a partir do Discourse/2.9.0.beta3.
O evento de webhook do Discourse parou de funcionar agora.
Esta é a configuração
URL de carga útil: http://nome-do-servidor:porta/rest : Este é o serviço interno de API REST que definimos.
Quando tento salvar este valor, ele gera o seguinte erro:
“Ocorreu um erro: A URL de carga útil não pode ser usada porque resolve para um IP bloqueado ou interno”
O mesmo valor para a URL de carga útil: http://nome-do-servidor:porta/rest costumava funcionar bem na
versão do Discourse Discourse/2.9.0.beta3.
Algo foi atualizado na versão mais recente do Discourse, ou isso é um bug?
Isso não parece certo. A URL de carga útil para webhooks pode, de fato, ser um recurso interno se o Discourse for auto-hospedado. Não tenho certeza por que você gostaria de parar de poder configurar URLs ou endereços que se resolvem internamente para processar webhooks. Parece ter havido uma mudança para impedir URLs de sites inválidos/ruins em perfis de usuário. Essa mudança se infiltrou na validação da URL de carga útil do webhook?
Porque também pode ser uma questão de segurança onde um administrador do Discourse poderia usar webhooks para descobrir ou atacar recursos internos em uma rede que não é deles?
Sim, movi isso para Feature, isso pode ser usado para extrair informações sobre uma rede interna. Existem algumas opções para ajustar o comportamento em uma instância específica.
Nossa instância auto-hospedada também é afetada por isso. Gostaríamos de hospedar o serviço que recebe o webhook apenas na rede docker interna; não há necessidade de ele ser acessível de fora.
Existe uma maneira de permitir webhooks internos?
Se entendi o problema corretamente, webhooks internos não são permitidos para que um administrador do Discourse, que não tem permissão de administrador do servidor, não possa espionar os internos da rede. No entanto, isso não é um problema em nossa instância auto-hospedada; nossos administradores do Discourse saberiam de nossa estrutura interna de qualquer maneira.
Sugeriria uma configuração no arquivo de configuração app.yml para permitir webhooks internos, ou para fornecer uma lista de permissões de domínios/IPs internos. Dessa forma, o administrador do servidor (não o administrador do Discourse) permanece no controle de quem pode usar webhooks para a rede interna.
Encontrei uma configuração que permite desbloquear hosts internos específicos e é respeitada pelo mecanismo de Proteção SSRF que está causando o bloqueio dos WebHooks em primeiro lugar:
Use a configuração allowed_internal_hosts para especificar quais nomes de host internos são permitidos em seu webhook.