Ich hoffe, jemand kann mir sagen, was ich hier falsch mache.
Ich habe einen Discourse Webhook eingerichtet und er funktioniert wie erwartet ohne ein Secret. Dann schreibe ich einen String in das Secret und kopiere diesen String dann in den empfangenden Webhook als Header, so:
X-Discourse-Event-Signature: secret_here
Dies führt zu folgendem Fehler im Body, wenn der sendende Webhook gesendet wird:
{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}
Ich gehe davon aus, dass ich es einfach nicht richtig mache, also klären Sie mich bitte auf!
Mir ist bewusst, dass das Secret mit sha256 verschlüsselt wird, also ist der gesendete Header:
X-Discourse-Event-Signature: sha256=XXX
Aber ich bin mir nicht sicher, was ich mit diesen Informationen in den Security Headers des empfangenden Webhooks machen soll.
Ich bin mir nicht sicher, ob dies nur die Art und Weise ist, wie Sie den Beitrag schreiben, aber der eigentliche Header wäre
X-Discourse-Event-Signature: XXX
Sie können dies (optional) am empfangenden Ende verwenden, um zu überprüfen, ob der Webhook tatsächlich von Discourse gesendet wurde. Wenn Sie die Überprüfung nicht durchführen, könnte ein böswilliger Akteur potenziell Webhook-Ereignisse fälschen.
Sie schlagen also vor, dass die Signatur im empfangenden Webhook das verschlüsselte Geheimnis sein sollte, NICHT das unverschlüsselte gewählte Geheimnis?
Ich schreibe den Header in der empfangenden Anwendung tatsächlich so: X-Discourse-Event-Signature: XXX
Ich erhalte jedoch weiterhin einen 401 Forbidden-Fehler, wenn ich ein Geheimnis verwende.
Meine Wordpress-Website. Ich benutze ein Wordpress-Plugin, um Webhooks zu empfangen. Wenn ich keinen Security Header (Secret) hinzufüge, funktioniert der Webhook einwandfrei. Nur wenn ich das Secret hinzufüge, tritt das Problem auf.
Benutzerdefinierte Sicherheits-Header können im eingehenden Webhook-Trigger enthalten sein, aber eine wichtige Anmerkung ist, wie WordPress Bindestriche in Unterstriche ändern kann. Zum Beispiel kann die Verwendung von „x-api-key“ erfordern, stattdessen „x_api_key“ zu verwenden.
Ich habe jedoch eine verwandte Frage, @RGJ. Nehmen wir an, mein Geheimnis ist „1234“. Sollte im empfangenden Webhook der Wert von X-Discourse-Event-Signature sein:
Es sieht so aus, als ob das von Ihnen verwendete Wordpress-Plugin nur mit einem statischen Header-Wert verglichen werden kann, nicht mit einer dynamischen Signatur. Das ist etwas Discourse-spezifisches.
Ich habe inzwischen festgestellt, dass sich der SHA-Wert jedes Mal ändert, wenn der Webhook gesendet wird. Daher würde es nicht funktionieren, den SHA-Wert in den empfangenden Webhook einzufügen. Ich würde denken, dass es Beispiel Nr. 1 sein müsste, und wie Sie (erneut statischer Header) vorschlagen, müsste das Plugin den Hash tatsächlich dekodieren, bevor es die Header-Antwort generiert?
Zusammenfassend lässt sich sagen, dass ich den gehashten X-Discourse-Event-Signature nicht in diesem Plugin verwenden kann, da es nur statische Werte akzeptiert.
Ist es unsicher, einen Webhook ohne ein Geheimnis zu verwenden? Ich würde Benutzerereignisse von meinem Discourse an meine Hauptwebsite senden, wobei eine nicht offensichtliche URL wie main-site.com/wp-json/fol/fil/532563-5312534 verwendet wird. Ich kann auch statische Header hinzufügen, die beim empfangenden Hook übereinstimmen müssen.
Könnten Sie mir ein Beispiel für eine Anwendung geben, die einen dynamisch wechselnden HMAC verarbeiten könnte?
Der Wert wird gegen die Nutzlast des Webhooks berechnet, daher wird er für jede Anfrage anders sein.
Das ist eine interessante Frage. Die einzige Anwendung, die ich kenne, ist das WP Discourse-Plugin, aber es wurde speziell für die Handhabung von Discourse-Webhooks konfiguriert. Wenn die Implementierung von Discourse es den Leuten erschwert, Webhooks mit Geheimnissen zu validieren, muss das vielleicht untersucht werden.
Das überlasse ich anderen zu beantworten.
Wenn Sie Bedenken haben, den Webhook nicht zu validieren, hat das Plugin “Incoming Webhook Triggers” möglicherweise einen Action-Hook in seinem Code zur Webhook-Empfang, der ausgelöst wird, bevor die Daten des Webhooks verarbeitet werden. Wenn ja, sollte es möglich sein, eine Funktion zu schreiben, die sich daran anhängt, prüft, ob die Daten für einen Discourse-Webhook bestimmt sind, und dann das Geheimnis mit etwas wie dem Code validiert, den ich in meinem vorherigen Beitrag verlinkt habe.
Ich war neugierig und habe mich ein wenig damit beschäftigt. Ich bin mir nicht sicher, welche Anwendungen so konfiguriert sind, dass sie eine dynamisch wechselnde HMAC-Signatur empfangen, aber die Authentifizierung von Webhook-Anfragen mit einer HMAC-Signatur, die gegen die Nutzlast berechnet wird, ist eine ziemlich gängige Praxis für Anwendungen, die Webhooks senden. Zum Beispiel verwenden GitHub, Stripe und Shopify diese Methode.
Es gibt auch einige beliebte Anwendungen, die die Secret-Token-Methode zur Authentifizierung von Webhooks verwenden. Zum Beispiel (Stand 2021) verwenden Mailchimp, Trello, Slack und Discord diesen Ansatz. Es scheint, dass Slack diese Methode immer noch verwendet: Slack developer FAQ | Slack Developer Docs. Ich kann verstehen, wie das die Anwendung, die den Webhook empfängt, erleichtern würde.
Ich denke, es gibt einen Kompromiss zwischen Sicherheit und Komfort bei der Entscheidung, welche Methode die sendende Anwendung verwenden wird. Meine Sorge bei Discoures HMAC-Signaturmethode ist, dass dies dazu führen könnte, dass Leute Webhooks ohne geheime Schlüssel konfigurieren, um die Schwierigkeit der Handhabung der sich ändernden HMAC-Signaturen zu umgehen. Zum Beispiel gibt es auf Meta einige Hinweise zum Senden von Discourse-Webhooks an Zapier, ohne dass erwähnt wird, wie die Signatur auf Zapier validiert werden kann. (Es sollte technisch möglich sein, die Signaturen auf Zapier zu validieren. Ich bin im Moment nicht in der Lage, das zu testen.)
Ich stimme dem absolut zu. Vielleicht ist dies etwas, das die Entwickler untersuchen können – eine einfachere und kompatiblere Methode zur Sicherung von Webhook-Daten.
Außerdem bin ich mir nicht so sicher, ob Zapier überhaupt in der Lage ist, die Signatur zu validieren.
Die Webhook-Geheimfunktion wird gemäß folgendem implementiert:
Es scheint, dass die von Ihnen gewünschte Software diese Standard-Sicherheitskommunikationsfunktion nicht unterstützt, Sie können jedoch weiterhin Discourse-Webhooks ohne sie verwenden.
Es gibt keine Pläne, einen festen Header mit einem gemeinsamen Geheimnis hinzuzufügen, da dessen Sicherheitswert fragwürdig ist. Wenn Sie dies jedoch benötigen, sollte es in einem Plugin umsetzbar sein.
