「Webhookは本質的に安全ではない」 知らないと危険なリスクと対策を解説：攻撃者からシステムを守るための実践的ガイド

TechTargetは2024年12月10日、「Webhookのセキュリティ」に関する記事を公開した。脅威からWebhookエコシステムを保護し、安全に維持するためには、Webhookを提供する側と利用する側の双方が責任を持つ必要がある。

[Twain Taylor，TechTarget]

印刷

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

　TechTargetは2024年12月10日（米国時間）、「Webhookのセキュリティ」に関する記事を公開した。

Webhookのセキュリティ：リスクとリスク緩和策のベストプラクティス（TechTarget）

　CI/CD（継続的インテグレーション／継続的デリバリー）パイプライン、チャットアプリケーション、eコマースプラットフォーム、IoT（Internet of Things）デバイスなど、Webhookは、多くのシステムにおいてリアルタイムの更新を実現するシンプルかつ効果的な仕組みとして利用されている。

　Webhookはイベント駆動型アーキテクチャにおいて効率的な通信を実現する。だが、外部に公開されるコンポーネントである以上、Webhookエンドポイントは慎重に実装し、正規のリクエストのみを処理できるようにしなければならない。また、潜在的なセキュリティ脅威から保護する対策も不可欠だ。

Webhookは安全なのか

続きを読む

　Webhookは本質的に安全なものではない。WebhookのURLは、外部サービスからのリクエストを受け取るサーバのエンドポイントだからだ。

　通常、エンドポイントは公開されているため、Webhookのライフサイクルのさまざまな段階で潜在的な脆弱性が発生する可能性がある。そのため、Webhookのセキュリティは実装の方法とメンテナンスの方針に左右される。

　ここではまず、Webhookを使用する際に考慮すべき主なセキュリティリスクについて説明する。

リプレイ攻撃（Replay Attacks）

　リプレイ攻撃とは、攻撃者が正規のリクエストを入手（傍受）し、そのリクエストを再送信することで標的となるシステムを欺く攻撃だ。傍受は通常、脆弱（ぜいじゃく）なエンドポイントを通じて実行される。攻撃者は正規の送信者になりすまし、入手したリクエストを標的とするシステムに再送信（リプレイ）するため、システムはこれを正当なものとして処理してしまう。

　リプレイ攻撃が容易に実行される理由の一つは、HTTP通信がステートレス（状態を保持しない）だからだ。受信側のシステムは、オリジナルのリクエストと再送信されたリクエストを区別できないため、どちらも新しいリクエストとして処理してしまう。例えば、攻撃者が決済確認のWebhookリクエストを傍受して再送信すれば、同じ取引を複数回処理させることができる。

サーバサイドリクエストフォージェリ（SSRF：Server-Side Request Forgery）

　SSRF攻撃とは、ユーザーが指定したURLを、攻撃者が改ざんし、サーバのリクエストを意図しないリソース（例えば、内部データベースやクラウドのメタデータサービスなど）に転送させる攻撃だ。

　Webhookシステムは、その仕組み上、SSRF攻撃の影響を受けやすい。Webhookには基本的な機能として、ユーザーが通知を受け取るためのコールバックURLを指定できる。だが、この仕組みはユーザー入力を信頼する設計になりやすく、攻撃者によるサーバサイドリクエストの操作を許してしまう可能性がある。

中間者攻撃（MiTM：Man-in-the-Middle Attacks）

　MiTMとは、その名の通り、Webhookの送信者と受信者の間に攻撃者が割り込み、HTTPリクエストを傍受することで発生する攻撃だ。攻撃者は、Webhookのペイロード（リクエストのデータ）を盗み見たり、改ざんしたり、さらには完全に偽装したデータを作成して本来の受信者に転送できる。

　Webhookに対するMiTMは、主にセキュリティ対策が不十分なエンドポイントや、暗号化されていない通信を狙って実行される。攻撃者は、Webhook送信者と受信者の間にあるネットワークインフラを侵害することで通信を傍受できる他、DNSスプーフィング（ドメインネームシステムの偽装）などの手法を用いてWebhookのトラフィックを自らのシステム経由で転送させ、通信内容を操作することも可能だ。

分散型サービス拒否（DDoS：Distributed Denial-of-Service）攻撃

　DDoS攻撃とは、Webhookのエンドポイントを標的とし、マルウェアに感染した複数のデバイス（ボットネット）から大量のリクエストを送りつけることで、サーバの負荷を急激に増大させ、処理速度を低下させたり、完全にダウンさせたりする攻撃だ。これによって、サービスの正常な利用が妨害されるため、サービス拒否攻撃と呼ばれる。

　DDoS攻撃は、Webhookのセキュリティにおいて大きな懸念事項だ。なぜなら、Webhookはリアルタイムのデータ同期や通知の配信を担うため、攻撃によって業務の重要なプロセスが停止する可能性があるからだ。例えば、Webhookが企業の在庫管理システムとeコマースプラットフォームのデータを同期している場合、DDoS攻撃によってこのプロセスが妨害されると、在庫数の更新が遅れ、欠品や注文未処理といった問題が発生する恐れがある。

Webhookのセキュリティを強化する5つのベストプラクティス

　Webhookのセキュリティは、プロバイダー（Webhookを提供する側）とコンシューマー（Webhookを利用する側）の双方が責任を持ち、適切な対策を講じることで実現する。以下のベストプラクティスを実践することで、両者の視点からリスクを軽減できるだろう。

1．HTTPSを使ってデータを暗号化する

　Webhookを保護する最も基本的な方法は、リクエストの送受信を常にHTTPS接続で実施するようにサーバを構築することだ。

　HTTP接続の場合、データは平文（暗号化なし）で送信するため、攻撃者に傍受されると内容がそのまま読み取られてしまう。一方、HTTPS接続はTLS/SSL（Transport Layer Security/Secure Socket Layer）プロトコルを使用して通信を暗号化するため、リクエストが傍受されても、攻撃者は（復号鍵がない限り）データを読み取ることも改ざんすることもできない。

2．Webhookを使って機密データを送信しない

　Webhookはリアルタイムのイベント通知に適しているが、セキュリティ機能が限定的であるため、機密データの送信には適さない。機密情報を扱う場合は、Webhookではなく、強力な認証機構を備えたAPIを使用して安全な通信を確保するべきだ。

　ベストプラクティスとしては、Webhookでは最小限の非機密データ（例えばイベントタイプやIDなど）のみを送信し、受信側のシステムがAPIを通じて必要な機密データを取得するように設計することだ。この方法を採用することで、Webhookで素早い通知を実現しつつ、適切に保護された経路で機密データのやりとりができる。

3．提供側と利用側を認証する

　ほとんどのエンドポイントは公開されているため、リクエストが信頼できるソースからのものかどうかを確認するために、Webhookリクエストを検証することが重要だ。

　受信リクエストの送信元IPアドレスを確認することでこうした検証が可能になる。「GitHub」は、サーバでIPの許可リストを設定するのに便利な「IPの範囲のリスト」を提供している。現在のIPアドレスを見つけるには、GitHubの「GET /meta」エンドポイントを使用する。許可リストのアドレスは変更される可能性があるため、定期的に更新するようにする。

　承認済みのユーザーだけがWebhookサービスとやりとりできるように、利用側を認証することも検討する。こうした相互認証では、例えば、接続中にクライアントとサーバに有効なデジタル証明書の提示を求めるといった手法が有効だ。

4．メッセージを検証するためにWebhookに署名する

　悪意のある攻撃者は、MiTMによってWebhookメッセージを改ざんする可能性がある。しかも、攻撃者が暗号化プロセスまで侵害した場合、暗号化されたリクエストであっても改ざんされる可能性がある。ハッシュベースのメッセージ認証コード（HMAC）を使用してWebhookに署名することで、このリスクを軽減させることができる。

　HMACは、暗号化ハッシュ関数と秘密鍵の両方を使用する特定種類のメッセージ認証コードだ。Webhookの実装では、Webhookプロバイダーがこの共有秘密鍵を使用して、送信前にペイロードごとにHMAC署名を生成し、リクエストヘッダに配置する。

　Webhookの利用側は、受信したペイロードと自分の秘密鍵のコピーを使用してHMACを再計算し、提供された署名と比較する。署名が一致すれば、ペイロードの整合性を検証でき、正当な提供側からのリクエストであることが確認できる。

5．メッセージにタイムスタンプを付けて送信する

　ペイロードの内容を検証するには署名が役立つ。一方、リプレイ攻撃の防止に役立つのは、メッセージの時刻を確認することだ。

　検証方法としては、署名を生成する前にペイロードにメッセージの有効期限のタイムスタンプを追加するのが一般的だ。攻撃者がタイムスタンプを変更しようとすると、署名が無効になるため、「その処理を実施すべきではない」といった旨のアラートが送信される。

　この検証プロセスをさらに強化するなら、サーバとWebhook提供側との間でネットワークタイムプロトコル（NTP）同期を実装するのがいいだろう。これによって、両方のシステムが同じ正確な時間基準で動作し、メッセージの有効性に対する「信頼性のある時間枠」を確立できる。

Webhookのセキュリティは継続が重要

　Webhookのセキュリティは、継続的な監視が必要なプロセスであることを忘れてはならない。Webhookを安全にするために推奨されるベストプラクティスに加えて、Webhookエンドポイントの包括的なヘルスチェック、パフォーマンス指標、可用性の監視が必要だ。それらを継続させることで、Webhookは、セキュリティ脅威に対して強固であり続けることができる。