Webhookシークレットの問題

サポート
1

ここで何が間違っているのか教えていただけますか？

Discourse Webhook を設定しましたが、シークレットなしでは期待どおりに動作します。次に、シークレットに文字列を書き込み、その文字列を受信 Webhook のヘッダーに次のようにコピーします。

X-Discourse-Event-Signature: secret_here

これにより、送信 Webhook が送信されたときに、本文に次のエラーが表示されます。

{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}

私が正しく行っていないのだと思いますが、教えてください！

シークレットは sha256 を使用して暗号化されていることは認識しているので、送信されるヘッダーは次のようになります。

X-Discourse-Event-Signature: sha256=XXX

しかし、受信 Webhook のセキュリティ ヘッダーでこの情報と何をすべきかはわかりません。

2

これが投稿の書き方なのか、それとも実際のヘッダーは次のようになります。

X-Discourse-Event-Signature: XXX

受信側で、Webhookが実際にDiscourseによって送信されたことを検証するために（オプションで）これを使用できます。検証を行わない場合、悪意のある当事者がWebhookイベントを偽造する可能性があります。

これはどういう意味ですか？

「いいね！」 1
3

受信Webhookの署名は、暗号化されていないシークレットではなく、暗号化されたシークレットであるべきだと提案されているということでしょうか？

受信アプリケーションでヘッダーを次のように記述しています。
X-Discourse-Event-Signature: XXX

しかし、シークレットを使用すると常に401 Forbiddenエラーが発生します。

CleanShot 2023-08-20 at 12.41.40@2x
CleanShot 2023-08-20 at 12.41.40@2x2192×398 25.7 KB

4

そのスクリーンショットはどこからですか？
あなたのセットアップについてもう少し詳しく説明していただけますか。

5

私のWordPressウェブサイトです。Webhookを受信するためにWordPressプラグインを使用しています。セキュリティヘッダー（シークレット）を追加しない場合、Webhookは正常に機能します。問題が発生するのは、シークレットを追加した場合のみです。

プラグインはこちらです：Incoming Webhook Triggers - Uncanny Automator

お時間をいただきありがとうございます、リチャード！

「いいね！」 1
6

問題は絞り込みました。

カスタムセキュリティヘッダーは受信Webhookトリガーに含まれる場合がありますが、WordPressがダッシュをアンダースコアに変更する可能性があるという重要な注意点があります。たとえば、「x-api-key」を使用しようとすると、「x_api_key」を使用する必要がある場合があります。

しかし、関連する質問があります @RGJ 。秘密鍵が「1234」だとしましょう。受信Webhookでは、X-Discourse-Event-Signature の値は次のようになりますか？

  1. 1234;
  2. sha256=encrypted_value_here;
  3. encrypted_value_here

？

7

それは#2のsha256=XXXです。

使用しているWordPressプラグインは、動的な署名ではなく、静的なヘッダー値と比較することしかできないようです。これはDiscourse固有のものです。

「いいね！」 1
8

WP Discourseプラグインがシークレットをどのように扱っているか確認してください。

「いいね！」 5
9

Webhook が送信されるたびに SHA 値が変更されることが判明したため、受信 Webhook に SHA 値を含めても機能しません。例 #1 が必要であり、あなたが示唆しているように（再静的ヘッダー）、プラグインはヘッダー応答を生成する前にハッシュをデコードする必要があるのでしょうか？

結論として、ハッシュ化された X-Discourse-Event-Signature は静的値しか受け付けないため、このプラグインでは使用できないと思います。

シークレットなしで Webhook を使用するのは安全ではありませんか？ Discourse からメインの Web サイトにユーザー イベントを送信します。main-site.com/wp-json/fol/fil/532563-5312534 のような明白ではない URL を使用します。受信フックで一致する必要がある静的ヘッダーを追加することもできます。

動的に変化する HMAC を処理できるアプリケーションの例を教えていただけますか？

10

値はWebhookのペイロードに対して計算されるため、リクエストごとに異なります。

それは興味深い質問ですね。私が知っている唯一のアプリケーションはWP Discourseプラグインですが、DiscourseのWebhookを処理するために特別に設定されていました。Discourseの実装が、人々がシークレットでWebhookを検証するのを妨げている場合、それは調査する必要があるかもしれません。

それは他の人に答えてもらいましょう。

Webhookを検証しないことを心配している場合は、Incoming Webhook Triggersプラグインに、Webhookデータが処理される前にトリガーされるアクションフックがWebhook受信コードにあるかもしれません。もしそうであれば、それにフックする関数を記述し、データがDiscourseのWebhook用であるかどうかを確認し、次に私の以前の投稿でリンクしたコードのようなものでシークレットを検証することが可能になるはずです。

「いいね！」 2
11

興味があったので、少し調べてみました。動的に変化するHMAC署名を_受信_するように構成されたアプリケーションについてはよくわかりませんが、ペイロードに対して計算されたHMAC署名でWebhookリクエストを認証することは、Webhookを_送信_するアプリケーションにとってはかなり標準的なプラクティスです。たとえば、GitHub、Stripe、Shopifyはすべてこの方法を使用しています。

また、Webhook認証にシークレットトークン方式を使用している人気のアプリケーションもいくつかあります。たとえば（2021年現在）、Mailchimp、Trello、Slack、Discordはすべてこのアプローチを使用しています。Slackはまだこの方法を使用しているようです：Slack developer FAQ | Slack Developer Docs

送信側アプリケーションがどちらの方法を使用するかを決定する際には、セキュリティと利便性のトレードオフがあると思います。DiscourseのHMAC署名方式に関する私の懸念は、人々が変化するHMAC署名の処理の難しさを回避するために、シークレットキーなしでWebhookを構成してしまう可能性があることです。たとえば、Metaには、Zapierで署名を検証する方法について言及せずにDiscourse WebhookをZapierに送信することに関する参照がいくつかあります。（Zapierで署名を検証することは技術的には可能であるはずです。現時点ではテストする準備ができていません。）

「いいね！」 2
12

まったく同感です。これは開発者が検討できることかもしれません。Webhookデータを保護するための、より簡単で互換性の高い方法です。

また、Zapierが署名を検証できるかどうかさえ定かではありません。

13

Webhookシークレット機能は、以下の仕様に従って実装されています。

ご希望のソフトウェアはこの標準的なセキュリティ通信機能をサポートしていないようですが、それでもDiscourse Webhookはそれなしで利用できます。

固定ヘッダーに共有シークレットを追加する計画はありません。そのセキュリティ上の価値は疑問視されているためです。ただし、これが必要な場合は、プラグインで実現可能であるはずです。

「いいね！」 4