Zoom Webhook認証方式を理解する
Webhook認証の必要性
Webhookは「プッシュ型API」として、リアルタイムなデータ連携を可能にする一方で、独特のセキュリティ課題を抱えています。通常のAPI呼び出しと異なり、Webhookでは受信者側がリクエストの発信者を制御できないため、なりすましや改ざん攻撃のリスクが高くなります。
Zoom Webhookでは、会議の録画データや参加者情報といった機密性の高い情報を扱うため、送信者（Zoom）と受信者（開発者のサーバー）の双方を保護する二重の認証メカニズムを採用しています。
本記事では、Zoom Webhook公式ドキュメントに基づいて二重の認証メカニズムついて解説します。
2つの認証方式とその役割
Zoom Webhookの認証システムは、異なる脅威モデルに対応する2つの検証プロセスで構成されています：
| 認証方式 | 目的 | 実行タイミング | 実装者 |
|---|---|---|---|
| Endpoint URL Validation | エンドポイントの所有権確認 | 初回設定時 + 72時間ごと自動再検証 | Zoom側が実行 |
| Signature Verification | Webhookの真正性確認 | 全Webhook受信時 | 受信者側が実装 |
この2段階認証により、送信者と受信者が互いの正当性を確認し合う相互認証を実現しています。
1. Endpoint URL Validation：送信者(Zoom)保護のための事前認証
解決する課題
問題：設定ミスによるデータ漏洩
開発者が間違ったURLを設定した場合や、攻撃者が正当なエンドポイントになりすました場合、Zoomの機密データが意図しない宛先に送信されるリスクがあります。特に以下のような現実的なシナリオが考えられます：
-
設定ミス:
https://example.com/webhookをhttps://attacker.com/webhookと誤入力 - ドメイン乗っ取り: 期限切れドメインを攻撃者が取得
- 内部者攻撃: 悪意のある開発者による意図的な設定変更
技術的防御メカニズム
Zoomでは独自のchallenge-response check (CRC)による検証システムを採用しています。
これより、エンドポイントの所有者が本当にWebhookを受信する意図があることを確認します。
認証フロー
継続的な再検証
Zoomは72時間ごとに自動再検証を実行し、エンドポイントの継続的な正当性を確認します。
これにより、設定後にドメインが乗っ取られた場合でも迅速に検出・遮断できます。
攻撃者視点での防御分析
シナリオ: エンドポイントなりすまし攻撃を試行
攻撃者の行動：
1. 開発ドキュメントやGitHubから漏洩したWebhook URLを発見
2. 攻撃者サーバーに同じエンドポイントを設定
3. Zoomの管理画面で誤って攻撃者のURLを登録させる試み
4. ZoomからのChallenge（plainToken）を受信
5. Secret Tokenを知らずに適当なレスポンスを生成して返送
防御の結果：
→ 攻撃者はSecret Tokenを知らないため、正しいHMAC-SHA256(Secret_Token, plainToken)を計算できない
→ Zoomが同じ計算を実行して攻撃者のレスポンスと比較
→ 計算結果が一致せず偽サーバーと判定
→ 攻撃失敗：該当エンドポイントへのWebhook送信を停止
2. Signature Verification：受信者保護のためのリアルタイム認証
解決する課題
受信者側が直面する現実的な脅威は以下の通りです：
データ改ざん攻撃
- プロキシサーバーやCDNでの意図しないデータ変更
- ネットワーク機器の設定ミスによるヘッダー書き換え
なりすまし攻撃
- 攻撃者がZoomのふりをして偽のWebhookを送信
- 悪意のあるURLやマルウェアを含むペイロードの注入
リプレイ攻撃
- 過去の正当なWebhookを記録し、後で再送信
- システムに古いイベントを重複処理させる
技術的防御メカニズム
Zoom側で生成した署名をHTTPヘッダーに含めることで、各Webhookの完全性と真正性を保証します。
署名生成・検証フロー
攻撃者視点での防御分析
シナリオ1：データ改ざん攻撃を試行
攻撃者の行動：
1. ネットワーク上でZoomのWebhookを傍受
2. URLを悪意のあるサイトに書き換え
3. 改ざんしたデータを受信者サーバーに送信
防御の結果：
→ 攻撃者はSecret Tokenを知らないため、改ざん後のデータに対する正しい署名を生成できない
→ 受信者の署名検証で改ざんが検知される
→ 攻撃失敗：HTTP 401で拒否
シナリオ2：リプレイ攻撃を試行
攻撃者の行動：
1. 過去の正当なWebhookを記録・保存
2. 数時間後に同じWebhookを再送信
3. システムに古いデータを処理させようと試行
防御の結果：
→ タイムスタンプが300秒の許容範囲を超えている
→ 受信者のタイムスタンプ検証で古いリクエストと判定
→ 攻撃失敗：HTTP 401で拒否
シナリオ3：完全偽造攻撃を試行
攻撃者の行動：
1. Webhook URLを発見または推測
2. Zoomになりすまして偽のWebhookを作成
3. マルウェアURLを含む偽データを送信
防御の結果：
→ 攻撃者はSecret Tokenを知らないため、正しい署名を生成できない
→ 受信者の署名検証で偽造が検知される
→ 攻撃失敗：HTTP 401で拒否
シナリオ4：複合攻撃を試行
攻撃者の行動：
1. 過去のWebhookを傍受・記録
2. データ部分を悪意のあるURLに改ざん
3. 古いタイムスタンプのまま改ざんデータを送信
4. 複数の防御を同時に突破しようと試行
防御の結果：
→ データ改ざんにより署名が不一致（署名検証で検知）
→ 同時に古いタイムスタンプで時間制限違反（タイムスタンプ検証で検知）
→ 攻撃失敗：両方の防御により完全阻止
本記事は、Zoom公式ドキュメント（2025年7月版）に基づいて作成されています。実装時は最新の公式ドキュメントと併せてご参照ください。
Discussion