I have recently upgraded my discouse instance to Discourse/2.9.0.beta14 latest version from Discourse/2.9.0.beta3.
The discourse webhook event has stopped working now.
This is the configuration
payload URL: http://server-name:port/rest : This is the internal rest api service that we have defined.
When I try to save this value, it gives the following error:
“An error occurred: Payload URL cannot be used because it resolves to a blocked or internal IP”
The same value for payload URL: http://server-name:port/rest used to work fine in the
Discourse/2.9.0.beta3 discourse version.
Is there something that has been updated in the latest version of discourse, or is this a bug?
Please could you let me know. Thanking in advance.
This doesn’t sound right. The payload URL for webhooks may indeed be an internal resource if Discourse is self hosted. Not sure why you would want to stop being able to configure URLS or addresses that resolve internally for processing web hooks. There has been a change it seems to prevent invalid/bad website URLs on user profiles. Has that change crept into the validation for the webhook payload URL ?
Because it can also be a security issue where a Discourse admin could use webhooks to discover or attack internal resources on a network which is not theirs?
Yeah, moved this to feature, this can be used to fish information about an internal network. There are some knobs to tune the behavior on a specific instance.
Our self-hosted instance is affected by this, as well. We would like to host the service that receives the webhook only on the internal docker network; there’s no need for it to be reachable from outside.
Is there a way to allow internal webhooks?
If I understand the issue correctly, internal webhooks are not allowed such that a discourse admin, who is not entitled as a server admin, may not spy on network internals. This is not an issue on our self-hosted instance, though; our discourse admins would know about our internal structure anyway.
I would suggest a setting in the app.yml config to allow internal webooks, or to provide a whitelist of internal domains/IPs. This way, the server admin (not the discourse admin) remains in control of who may use webhooks for the internal network.
I found a setting that allows to unblock specific internal hosts and is respected by the SSRF Protection mechanism that is causing the WebHooks to be blocked in the first place:
Use the setting allowed_internal_hosts to specify which internal hostnames are allowed in your webhook.