7.4.3. メッセージコンポーネントの出所とコンテキスト (Message Component Source and Context)

7.4.3. メッセージコンポーネントの出所とコンテキスト (Message Component Source and Context)

メッセージコンポーネントの値を導出するための署名コンテキストには, 対象の HTTP メッセージ自体, 関連するメッセージ (レスポンスを引き起こしたリクエストなど), および署名者または検証者がアクセスできる追加情報が含まれる. 署名者も検証者も, 署名ベース用のコンポーネント値を作成するときにすべての情報の出所を慎重に考慮し, 信頼できない出所から情報を取り込まないよう注意する必要がある. さもなければ, 攻撃者は, 意図した値を上書きまたは破損させるために, 緩く定義されたメッセージコンテキストを悪用して署名ベース文字列に自身の値を注入しうる.

例えば, ほとんどの状況では, メッセージの target URI は [HTTP] の 7.1 節で定義されるとおりである. しかし, 着信リクエストの @authority の署名を要求するアプリケーションがあるとするが, 処理を行うアプリケーションはリバースプロキシの背後にある. そのようなアプリケーションは @authority の値の変化を想定し, プロキシの反対側のクライアントから見える外部 target URI を知るよう設定されている可能性がある. このアプリケーションは, 着信メッセージの target URI を用いる代わりに, @authority などのメッセージコンポーネント値を導出する目的で, この設定された値を target URI として用いる.

このアプローチは問題を伴わないわけではない. 誤設定されたシステムは, システム内の異なるコンポーネント向けに意図された署名付きリクエストを受け入れうる. このシナリオでは, 中間者が代わりにアプリケーションが直接検証する自身の署名を追加できる. 4.3 節で示すとおりである. この代替アプローチはより能動的な中間者を要するが, 対象アプリケーションが外部設定値を知ることへの依存は小さい.

別の例として, 2.4 節はレスポンスメッセージへの署名と, レスポンスを引き起こしたリクエストメッセージの部分の包含を定義する. この場合, コンポーネント値計算のコンテキストは, 署名が適用される単一のメッセージだけでなく, レスポンスとリクエストメッセージの組み合わせである. この機能について, req フラグにより, どのコンテキストの部分がコンポーネント識別子の値の出所として用いられているかを署名者の双方が明示的に示せる. 実装は, 各コンポーネントについて意図したメッセージのみが参照されることを確保する必要がある. さもなければ, 攻撃者は一方または他方を操作することで署名を潜り抜けようとしうる.