Ich habe meine Discourse-Instanz kürzlich von Discourse/2.9.0.beta3 auf die neueste Version Discourse/2.9.0.beta14 aktualisiert.
Das Discourse-Webhook-Ereignis funktioniert jetzt nicht mehr.
Dies ist die Konfiguration
Payload-URL: http://server-name:port/rest : Dies ist der interne REST-API-Dienst, den wir definiert haben.
Wenn ich versuche, diesen Wert zu speichern, erhalte ich die folgende Fehlermeldung:
„Ein Fehler ist aufgetreten: Die Payload-URL kann nicht verwendet werden, da sie auf eine blockierte oder interne IP-Adresse aufgelöst wird.“
Der gleiche Wert für die Payload-URL: http://server-name:port/rest funktionierte in der
Discourse/2.9.0.beta3 Discourse-Version einwandfrei.
Wurde in der neuesten Version von Discourse etwas aktualisiert, oder ist dies ein Fehler?
Könnten Sie mir bitte Bescheid geben. Vielen Dank im Voraus.
Das klingt nicht richtig. Die Payload-URL für Webhooks kann durchaus eine interne Ressource sein, wenn Discourse selbst gehostet wird. Ich bin mir nicht sicher, warum Sie die Möglichkeit einschränken möchten, URLs oder Adressen zu konfigurieren, die intern zur Verarbeitung von Webhooks aufgelöst werden. Es scheint eine Änderung gegeben zu haben, um ungültige/schlechte Website-URLs in Benutzerprofilen zu verhindern. Ist diese Änderung in die Validierung der Webhook-Payload-URL eingeflossen?
Weil es auch ein Sicherheitsproblem sein kann, bei dem ein Discourse-Administrator Webhooks verwenden könnte, um interne Ressourcen in einem Netzwerk zu entdecken oder anzugreifen, das nicht ihm gehört?
Ja, das wurde zu Feature verschoben. Dies kann verwendet werden, um Informationen über ein internes Netzwerk zu fischen. Es gibt einige Stellschrauben, um das Verhalten bei einer bestimmten Instanz zu optimieren.
Unsere selbst gehostete Instanz ist ebenfalls davon betroffen. Wir möchten den Dienst, der den Webhook empfängt, nur im internen Docker-Netzwerk hosten; er muss nicht von außen erreichbar sein.
Gibt es eine Möglichkeit, interne Webhooks zu erlauben?
Wenn ich das Problem richtig verstehe, sind interne Webhooks nicht erlaubt, damit ein Discourse-Administrator, der nicht als Server-Administrator berechtigt ist, keine Netzwerk-Interna ausspähen kann. Dies ist jedoch kein Problem auf unserer selbst gehosteten Instanz; unsere Discourse-Administratoren würden unsere interne Struktur sowieso kennen.
Ich würde eine Einstellung in der app.yml-Konfiguration vorschlagen, um interne Webhooks zu erlauben, oder eine Whitelist von internen Domains/IPs bereitzustellen. Auf diese Weise behält der Server-Administrator (nicht der Discourse-Administrator) die Kontrolle darüber, wer Webhooks für das interne Netzwerk verwenden darf.
Ich habe eine Einstellung gefunden, die es ermöglicht, bestimmte interne Hosts zu entsperren und die vom SSRF-Schutzmechanismus beachtet wird, der die WebHooks überhaupt erst blockiert:
Verwenden Sie die Einstellung allowed_internal_hosts, um anzugeben, welche internen Hostnamen in Ihrem Webhook zulässig sind.