Recentemente ho aggiornato la mia istanza di Discourse a Discourse/2.9.0.beta14, l’ultima versione, da Discourse/2.9.0.beta3.
L’evento webhook di Discourse ha smesso di funzionare.
Questa è la configurazione:
URL del payload: http://nome-server:porta/rest : Questo è il servizio API REST interno che abbiamo definito.
Quando provo a salvare questo valore, ricevo il seguente errore:
“Si è verificato un errore: l’URL del payload non può essere utilizzato perché risolve in un IP bloccato o interno”
Lo stesso valore per l’URL del payload: http://nome-server:porta/rest funzionava correttamente nella versione di Discourse Discourse/2.9.0.beta3.
C’è qualcosa che è stato aggiornato nell’ultima versione di Discourse, o si tratta di un bug?
Potreste per favore farmelo sapere. Grazie in anticipo.
Questo non suona giusto. L’URL del payload per i webhook può effettivamente essere una risorsa interna se Discourse è self-hosted. Non capisco perché si voglia impedire la configurazione di URL o indirizzi che si risolvono internamente per l’elaborazione dei webhook. Sembra che ci sia stata una modifica per impedire URL di siti web non validi/errati sui profili utente. Questa modifica è forse entrata nella convalida dell’URL del payload del webhook?
Perché può anche essere un problema di sicurezza in cui un amministratore di Discourse potrebbe utilizzare i webhook per scoprire o attaccare risorse interne su una rete che non è la propria?
Sì, spostato questo in Feature, questo può essere usato per pescare informazioni su una rete interna. Ci sono alcune manopole per regolare il comportamento su un’istanza specifica.
Anche la nostra istanza self-hosted è interessata da questo problema. Vorremmo ospitare il servizio che riceve il webhook solo sulla rete Docker interna; non c’è bisogno che sia raggiungibile dall’esterno.
Esiste un modo per consentire i webhook interni?
Se ho capito bene il problema, i webhook interni non sono consentiti in modo che un amministratore di Discourse, che non è autorizzato come amministratore del server, non possa spiare le interne della rete. Tuttavia, questo non è un problema sulla nostra istanza self-hosted; i nostri amministratori di Discourse sarebbero comunque a conoscenza della nostra struttura interna.
Suggerirei un’impostazione nella configurazione app.yml per consentire i webhook interni, o per fornire una whitelist di domini/IP interni. In questo modo, l’amministratore del server (non l’amministratore di Discourse) rimane in controllo di chi può utilizzare i webhook per la rete interna.
Ho trovato un’impostazione che consente di sbloccare host interni specifici ed è rispettata dal meccanismo di protezione SSRF che causa il blocco dei WebHook in primo luogo:
Utilizzare l’impostazione allowed_internal_hosts per specificare quali nomi host interni sono consentiti nel webhook.