Недавно я обновил свой экземпляр Discourse с версии Discourse/2.9.0.beta3 до последней версии Discourse/2.9.0.beta14.
Теперь вебхук-событие Discourse перестало работать.
Вот конфигурация:
URL полезной нагрузки: http://server-name:port/rest — это наш внутренний REST API-сервис.
При попытке сохранить это значение появляется следующая ошибка:
«Произошла ошибка: URL полезной нагрузки нельзя использовать, так как он указывает на заблокированный или внутренний IP-адрес».
Раньше тот же самый URL полезной нагрузки: http://server-name:port/rest работал корректно в версии Discourse/2.9.0.beta3.
Подскажите, что-то изменилось в последней версии Discourse, или это ошибка?
Это звучит неправильно. URL-адрес полезной нагрузки для вебхуков действительно может быть внутренним ресурсом, если Discourse размещён самостоятельно. Не понимаю, зачем вам нужно запретить настраивать URL-адреса или адреса, которые разрешаются внутренне для обработки вебхуков. Похоже, было внесено изменение, предотвращающее некорректные URL-адреса сайтов в профилях пользователей. Неужели это изменение затронуло и валидацию URL-адреса полезной нагрузки вебхука?
Потому что это также может стать проблемой безопасности: администратор Discourse может использовать веб-хуки для обнаружения или атаки на внутренние ресурсы сети, которая ему не принадлежит.
Да, перенёс это в #feature, это можно использовать для сбора информации об внутренней сети. Есть некоторые настройки для управления поведением на конкретном экземпляре.
Наша самохостинговая установка также затронута этой проблемой. Мы хотели бы размещать службу, принимающую вебхуки, только во внутренней сети Docker; нет необходимости делать её доступной извне.
Существует ли способ разрешить внутренние вебхуки?
Если я правильно понимаю проблему, внутренние вебхуки запрещены, чтобы администратор Discourse, не являющийся администратором сервера, не мог подсматривать внутренности сети. Для нашей самохостинговой установки это не является проблемой, поскольку наши администраторы Discourse всё равно осведомлены о нашей внутренней структуре.
Я предлагаю добавить настройку в конфигурационный файл app.yml для разрешения внутренних вебхуков или предоставить белый список внутренних доменов/IP-адресов. Таким образом, администратор сервера (а не администратор Discourse) останется контролировать, кто может использовать вебхуки во внутренней сети.
Я обнаружил настройку, позволяющую разблокировать определенные внутренние хосты, и она учитывается механизмом защиты от SSRF, который изначально блокирует вебхуки:
Используйте настройку allowed_internal_hosts, чтобы указать, какие внутренние имена хостов разрешены для вашего вебхука.