【ITニュース解説】Defending Webhooks: Preventing Signature Forgery, Replay Attacks, and Timing Attacks in Python

Webhooksとは、あるシステムで特定のイベントが発生した際に、別のシステムへ自動的に通知を送る仕組みである。例えば、オンラインストアで注文が入ったときに、在庫管理システムへ「注文があった」という情報をリアルタイムで送る、といった使われ方をする。非常に便利で広く使われているが、その性質上、セキュリティに十分な注意を払わないと重大な脆弱性につながる可能性がある。

Webhooksの初期実装では、届いたデータをそのまま処理するという単純な方法が取られがちである。しかし、この方法ではいくつかのセキュリティ上の問題が生じる。

第一に、「ペイロード改ざん」である。これは、Webhooksで送られてくるデータ（ペイロード）が、送信元から受信システムへ送られる途中で第三者によって不正に書き換えられたり、あるいは全くの第三者が本物になりすまして偽のデータを送ってきたりする脅威である。受信システムがデータの正当性を確認しなければ、偽の情報に基づいて誤った処理を実行してしまうことになる。例えば、実際には発生していない注文や、不正なユーザー情報の更新などがこれにあたる。

第二に、「リプレイ攻撃」である。これは、過去に一度正当なリクエストとして送られたデータが、第三者によって傍受され、それが何度も再送信される脅威である。Webhooksの受信システムが、同じリクエストが何度も送られてきてもそれを見分けられない場合、在庫が不必要に減らされたり、支払い処理が何度も実行されたり、あるいはシステムに過剰な負荷をかけてサービスを停止させるといった、サービス拒否（DoS）攻撃を引き起こす可能性がある。リクエストが「新鮮であること」を保証する仕組みがないと、この種の攻撃を防ぐことは難しい。

第三に、「タイミング攻撃」である。これは、システムが受け取ったデータの署名（データの正当性を証明するための情報）を検証する際に発生する、非常に巧妙な攻撃である。署名を比較する通常のプログラムでは、二つの文字列を文字の先頭から順番に比較し、一致しない文字が見つかった時点で比較を終了する。この「一致しない文字が見つかるまでの時間」のわずかな差を何千回、何万回と測定・統計することで、攻撃者は正しい署名の内容を少しずつ推測し、最終的に秘密情報を特定できる可能性がある。これは時間差が非常に小さいため、一見すると気づきにくいが、統計的な分析によって脅威となる。

これらの脆弱性に対処し、Webhooksを安全に利用するためには、受信したリクエストを厳格に検証する仕組みが必要である。その検証プロセスは、主に三つのステップで構成される。

まず、「ヘッダー構造の検証」である。これは、リクエストのヘッダーに、署名やタイムスタンプといった必要な情報が正しい形式で含まれているかをチェックする工程である。PythonのPydanticのようなツールを使うことで、期待されるヘッダーのスキーマ（構造やデータ型）に合致しているかを自動的に、かつ厳密に検証できる。これにより、不正な形式のリクエストを初期段階で拒否し、システムのさらなる処理を防ぐ。

次に、「鮮度（タイムスタンプ）の検証」である。これは、リクエストに付与されたタイムスタンプ（リクエストが送信された時刻）と、現在の時刻との差をチェックする工程である。例えば、タイムスタンプが現在の時刻から300秒（5分）以上離れているリクエストは、古すぎるものと判断して拒否する。この時間枠を設けることで、古いリクエストが再送信されるリプレイ攻撃を防ぐことができる。ただし、この対策は、瞬間的なリプレイ攻撃（例えば300秒以内に何度も同じリクエストが送信されるケース）には対応できないため、より高度な対策が必要な場合もあるが、多くのリプレイ攻撃には有効である。

最後に、「暗号学的署名の比較」である。これは、受信したデータの正当性を最も強力に保証する部分である。Webhooksの送信元は、特定の秘密鍵（受信側と共有している秘密の情報）と、リクエストのデータ（ペイロードとタイムスタンプ）を使って、HMAC-SHA256という暗号技術で署名を生成し、リクエストのヘッダーに含めて送信する。受信側は、同じ秘密鍵と受信したデータを使って独自の署名を計算し、その計算結果と、リクエストに含まれていた署名とを比較する。両者が完全に一致すれば、データが途中で改ざんされておらず、かつ正当な送信元から送られてきたことを確認できる。

この署名比較を行う際には、「タイミング攻撃」を防ぐための特別な注意が必要である。Pythonの標準的な文字列比較演算子である==は、文字を先頭から順に比較し、不一致があればすぐに終了してしまうため、比較にかかる時間が署名の一致度合いによって変わる可能性がある。この時間差が攻撃者に利用されるのを防ぐため、hmac.compare_digest()という関数を用いる。この関数は、比較する二つの文字列の長さが同じであれば、比較処理にかかる時間が常に一定になるように設計されている。これにより、比較処理の時間の差から秘密情報を推測されるリスクを完全に排除できる。

これらの検証機構を実装する上で、いくつか注意すべき点がある。

一つは、JSONデータをバイト列に変換する際の挙動の違いである。Pythonの標準的なjsonモジュールと、高速な処理で知られるorjsonモジュールでは、辞書をJSON形式の文字列に変換した際の戻り値の型が異なる場合がある。json.dumps()はUTF-8文字列を返すのに対し、orjson.dumps()はバイト列を返す。HMAC署名計算では常にバイト列を必要とするため、どちらのモジュールを使う場合でも、最終的に得られるデータがバイト列であることを保証するラッパー関数を用意することが重要である。これにより、予期せぬエラーを防ぎ、一貫した処理を実現できる。

もう一つは、「未加工のボディ」の重要性である。Webフレームワーク（FastAPI、Flask、Djangoなど）では、HTTPリクエストのボディ部分を自動的にJSONオブジェクトなどの使いやすい形式にパースする機能がある。しかし、署名検証を行う際には、フレームワークによってパースされる前の「完全に未加工の、オリジナルのバイトストリーム」に対して署名計算を行う必要がある。なぜなら、JSONデータのシリアライズ（データ構造をバイト列に変換する処理）は、辞書のキーの順序、空白の有無、数値の表現方法などによって、出力されるバイト列が微妙に異なる可能性があるからである。もし受信したJSONを一度パースして、それを再度シリアライズしたもので署名を計算すると、元の送信元が計算した署名と一致しない可能性が高く、正当なリクエストでも検証に失敗してしまう。そのため、必ずフレームワークがパースする前の生のバイトデータを取得して署名計算に利用しなければならない。

これらの対策を組み合わせることで、Webhooksのセキュリティを大幅に向上させることができる。ヘッダーの形式が正しいか、リクエストが古すぎないか、そして何よりもデータが改ざんされておらず、正規の送信元から送られたものであるかを確実に検証することは、安全なシステム運用の基礎となる。システムエンジニアを目指す上で、このようなセキュリティの考慮は、信頼性の高いソフトウェアを構築するために不可欠な知識である。