Webhookとセキュリティ #Security

Webhookで決済のような重要なイベントの情報ををやり取りする場合には、リクエストに対する認証、完全性が保証されていてほしいです。

認証が保証されていなければ、どんなリクエストを送ればいいかさえわかれば、誰でもなりすましてリクエストができてしまいます。

完全性が保証されていないと、途中でリクエストが改ざんされていてもわかりません。

実装者あるいは利用者として、どのような対策があるのか調べて考えてみました。

考えられる対策

対策	認証	完全性
1	○	✗
2	○	○

1の場合、リクエスト自体が見れてしまうと任意のメッセージを送れます。また完全性は保証されていません。
2の場合リクエスト自体には鍵が含まれていません。送信時に使う鍵とアルゴリズムがわかると任意のメッセージを送れます。

きちんとした証明書を使ったhttpsであれば、基本リクエスト自体が見られることは無いはずなので、1でも問題ないように思えます。
ただ、以下のようなことをしてしまい、更にその内容が見れるような状態にあると任意のリクエストが送れるようになってしまいます。

簡単に起こり得そうなので基本的には2が好ましいと思います。

しかし2は送信側にもロジックが必要です。自分がWebhook受け取り側で、送信者が2をしてくれない場合には受信側でできることは1になってしまいます。

触ったことのあるサービスではどのような実装になっているのかいくつか見てみました。

Checking Webhook Signatures | Stripe
- Stripe-SignatureヘッダにHMAC（SHA-256）のメッセージ認証コードがついてくる
- 鍵はendpoint secretとしてwebhook設定から見れる
- Stripe-Signatureはタイムスタンプも含むことでリプレイ攻撃の対策としている

Securing your webhooks | GitHub Developer Guide
- X-Hub-SignatureヘッダにHMAC（SHA-1）のメッセージ認証コードがついてくる
- 鍵は自分で生成したものをwebhook設定から設定する

自分にとってそこまで重要ではない情報なら気にしなくていい
Webhook提供者がメッセージ認証コードをつけてくれているならその検証をする
- 基本は提供されているライブラリ、ドキュメントにある実装を使う
- 自分で検証する場合には定数時間の文字列比較アルゴリズムを使う
  - Timing Attack対策
メッセージ認証コードがない場合、予測不可能性を持った乱数で認証トークンを生成してリクエストのURLに設定し検証する
- 上と同様、文字列比較は定数時間のアルゴリズムを使う
- URLにBasic認証の情報を含められるなら使う
  - 自分が使っているサービスでは使えないものがあった
- だめならリクエストパラメータに認証トークンを入れる
  - ログに残らないよう対策する
    - 例えばRailsだったらRails.application.config.filter_parametersに追加する