Spero che qualcuno possa dirmi cosa sto sbagliando qui.
Ho configurato un Webhook di Discourse e funziona come previsto senza un segreto. Quindi scrivo una stringa nel segreto, e poi copio quella stringa nel Webhook ricevente come Header, in questo modo:
X-Discourse-Event-Signature: secret_here
Questo produce il seguente errore nel Body quando viene inviato il webhook di invio:
{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}
Mi aspetto di non averlo fatto nel modo giusto, quindi illuminatemi!
Sono consapevole che il segreto è crittografato utilizzando sha256, quindi l’Header inviato è:
X-Discourse-Event-Signature: sha256=XXX
Ma non sono sicuro di cosa dovrei fare con queste informazioni negli Header di sicurezza del Webhook ricevente.
Non sono sicuro se questo sia solo il modo in cui stai scrivendo il post, ma l’intestazione effettiva sarebbe
X-Discourse-Event-Signature: XXX
Puoi (facoltativamente) usarlo all’estremità ricevente per convalidare che il webhook sia stato effettivamente inviato da Discourse. Se non esegui la verifica, una parte malintenzionata potrebbe potenzialmente falsificare eventi webhook.
Il mio sito web Wordpress. Sto usando un plugin Wordpress per ricevere Webhook. Se non aggiungo un Security Header (Secret), il Webhook funziona bene. È solo quando aggiungo il segreto che si verifica il problema.
Le intestazioni di sicurezza personalizzate possono essere incluse nel trigger webhook in arrivo, ma una nota importante è come WordPress può cambiare i trattini in underscore. Ad esempio, tentare di usare “x-api-key” potrebbe richiedere l’uso di “x_api_key” invece.
Ho comunque una domanda correlata, @RGJ. Supponiamo che il mio segreto sia “1234”. Nel webhook ricevente, il valore di X-Discourse-Event-Signature dovrebbe essere:
Sembra che il plugin di Wordpress che stai usando possa confrontare solo con un valore di intestazione statico, non con una firma dinamica. Questa è una cosa specifica di Discourse.
Ho scoperto in seguito che il valore sha cambia ogni volta che viene inviato il webhook, quindi inserire il valore sha nel webhook ricevente non funzionerebbe. Penserei che dovrebbe essere l’esempio n. 1 e, come credo tu stia suggerendo (intestazione statica), il plugin dovrebbe in realtà decodificare l’hash prima di generare la risposta dell’intestazione?
In conclusione, non credo di poter utilizzare la X-Discourse-Event-Signature con hash in questo plugin, perché accetterà solo valori statici.
È insicuro utilizzare un webhook senza un segreto? Invierò eventi utente dal mio Discourse al mio sito web principale, utilizzando un URL non ovvio come main-site.com/wp-json/fol/fil/532563-5312534. Posso anche aggiungere intestazioni statiche che devono corrispondere sul hook ricevente.
Potresti darmi un esempio di un’applicazione che potrebbe gestire un hmac che cambia dinamicamente?
Il valore viene calcolato rispetto al payload del webhook, quindi sarà diverso per ogni richiesta.
Questa è una domanda interessante. L’unica applicazione che conosco è il plugin WP Discourse, ma è stato configurato specificamente per gestire i webhook di Discourse. Se l’implementazione di Discourse impedisce alle persone di convalidare i webhook con segreti, forse è necessario esaminarla.
Lascerò che siano altri a rispondere.
Se sei preoccupato di non convalidare il webhook, forse il plugin Incoming Webhook Triggers ha un gancio di azione nel suo codice di ricezione del webhook che viene attivato prima che i dati del webhook vengano elaborati. Se lo fa, dovrebbe essere possibile scrivere una funzione che si agganci ad esso, verifichi se i dati sono per un webhook di Discourse, quindi convalidi il segreto con qualcosa di simile al codice che ho collegato nel mio post precedente.
Ero curioso, quindi ho approfondito un po’. Non sono sicuro riguardo alle applicazioni che sono configurate per gestire la ricezione di una firma HMAC che cambia dinamicamente, ma l’autenticazione delle richieste webhook con una firma HMAC calcolata sul payload è una pratica abbastanza standard per le applicazioni che inviano webhook. Ad esempio, GitHub, Stripe e Shopify utilizzano tutti questo metodo.
Ci sono anche diverse applicazioni popolari che utilizzano il metodo del token segreto per autenticare i webhook. Ad esempio (a partire dal 2021) Mailchimp, Trello, Slack e Discord utilizzano tutti questo approccio. Sembra che Slack stia ancora utilizzando questo metodo: Slack developer FAQ | Slack Developer Docs. Posso capire come ciò renderebbe le cose più facili per l’applicazione che riceve il webhook.
Suppongo che ci sia un compromesso tra sicurezza e convenienza nel decidere quale metodo utilizzerà l’applicazione mittente. La mia preoccupazione riguardo al metodo della firma HMAC di Discourse è che potrebbe portare le persone a configurare webhook senza chiavi segrete per aggirare la difficoltà di gestire le firme HMAC che cambiano. Ad esempio, ci sono alcuni riferimenti su Meta per l’invio di webhook Discourse a Zapier senza alcuna menzione su come convalidare la firma su Zapier. (Dovrebbe essere tecnicamente possibile convalidare le firme su Zapier, tuttavia. Al momento non sono configurato per testarlo.)
Sono assolutamente d’accordo. Forse è qualcosa che gli sviluppatori possono esplorare: un metodo più semplice e compatibile per proteggere i dati dei webhook.
Inoltre, non sono così sicuro che Zapier sia in grado di convalidare la firma.
La funzionalità del segreto webhook è implementata secondo questo standard:
Sembra che il software che desideri non supporti questa funzionalità di comunicazione di sicurezza standard, ma puoi comunque utilizzare i webhook di Discourse senza di essa.
Non ci sono piani per aggiungere un’intestazione fissa con un segreto condiviso, poiché il valore di sicurezza di tale funzionalità è discutibile. Tuttavia, se ne hai bisogno, dovrebbe essere realizzabile in un plugin.
