午前I問題

複数のHTTPサーバ（ロードバランサ、リバースプロキシ、オリジンサーバ等）を経由してリクエストが処理されるWebシステムに関する記述として、適切なものはどれか。

ア）全てのHTTPサーバ実装は、RFC等の仕様を完全に同一の方法で解釈するため、リクエストの解釈が経路上で食い違うことはあり得ない。

イ）フロントエンド（プロキシ等）とバックエンド（オリジンサーバ等）が、1つのHTTPリクエストに含まれるヘッダ（例えば Content-Length と Transfer-Encoding が両方存在する場合）の解釈方法について異なる判断をすると、両者の間で「リクエストの区切り」の認識にズレが生じることがある。

ウ）HTTPリクエストは常に1コネクションにつき1リクエストのみが送信されるため、複数リクエストの区切り解釈という概念自体が存在しない。

エ）HTTPSで通信を暗号化していれば、経路上のどのサーバも同一のリクエスト解釈を行うことが暗号仕様によって保証される。

午前I の解答・解説を見る

正解： イ

解説：

  • ア）不正解。実装によってHTTP仕様（特にあいまいな部分）の解釈は異なり得る。これがリクエストスマグリングの根本原因となる。
  • イ）正解。Content-Length（ボディ長を明示）と Transfer-Encoding: chunked（チャンク形式で終端を判定）が同一リクエストに両方含まれる場合、どちらを優先するかはサーバ実装によって異なることがあり、フロントエンドとバックエンドで解釈が食い違うと、悪意あるリクエストの一部を後続リクエストの先頭として誤認識させられる可能性がある。
  • ウ）不正解。HTTP/1.1のKeep-Alive（持続的接続）では1コネクション上に複数のリクエストが送信されるのが一般的である。
  • エ）不正解。HTTPSは通信路の暗号化・改ざん検知を提供するが、経路上の各サーバがHTTPメッセージをどう解釈するかという実装上の差異までは保証しない。

午前II問題

HTTPリクエストスマグリング攻撃の分類に関する記述のうち、最も適切なものはどれか。

ア）「CL.TEスマグリング」とは、フロントエンドが Content-Length を優先してリクエスト長を判断する一方、バックエンドが Transfer-Encoding を優先してチャンク終端を判断することで、両者の認識するリクエスト境界がずれる攻撃である。

イ）「TE.TEスマグリング」は、両サーバとも Transfer-Encoding のみを参照し常に同一の解釈をするため、原理的に成立しない攻撃分類である。

ウ）リクエストスマグリングは常にTLS通信のハンドシェイク段階で発生し、アプリケーション層のHTTPメッセージ解析とは無関係である。

エ）リクエストスマグリングは単一のサーバのみで完結する攻撃であり、プロキシやロードバランサを経由しないシステムでも同様に成立する。

午前II の解答・解説を見る

正解： ア

解説：

  • ア）正解。「CL.TE」はフロントエンドが Content-Length、バックエンドが Transfer-Encoding を優先するケース、「TE.CL」はその逆のケースを指す典型的な分類である。この解釈の不一致により、フロントエンドが1つのリクエストと見なした通信の一部を、バックエンドは「次のリクエストの先頭」として処理してしまう。
  • イ）不正解。「TE.TE」は両者とも Transfer-Encoding ヘッダを参照するが、ヘッダの難読化（例：Transfer-Encoding: xchunked や余分な空白、大文字小文字の混在など）に対する処理系の差異によって、片方だけがヘッダを無視するケースが発生し得るため、TE.TEスマグリングも実際に成立する分類である。
  • ウ）不正解。リクエストスマグリングはTLSハンドシェイクではなく、HTTPメッセージ（アプリケーション層）のパース・境界解釈の差異に起因する。
  • エ）不正解。リクエストスマグリングは、フロントエンドとバックエンドという解釈の異なる複数のHTTPサーバが連結された構成（リバースプロキシ、ロードバランサ、CDN等）で成立する攻撃であり、単一サーバ完結の構成では原理的に発生しない。

午後問題

F社のWebサービスは、CDN兼リバースプロキシ（フロントエンド）を経由して、社内のアプリケーションサーバ（バックエンド）にリクエストを転送する構成をとっている。両者の間はHTTP/1.1のKeep-Alive接続で維持され、複数リクエストが同一コネクション上で連続して処理される。

セキュリティ診断業者は、次のリクエストを送信する実験を行った。

POST / HTTP/1.1
Host: f-sha.example.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

診断の結果、フロントエンドは Content-Length: 13 を優先して13バイト（0\r\n\r\nの直後まで）を本リクエストの終端と判断し残りを無視したが、バックエンドは Transfer-Encoding: chunked を優先し、チャンクサイズ 0 を終端（最終チャンク）と解釈した後、残りの SMUGGLED という文字列を「同一コネクション上の次のリクエストの先頭部分」として処理してしまうことが判明した。この結果、後続の別利用者からの正規リクエストの先頭に SMUGGLED が連結され、バックエンドで誤って解釈される状態が確認された。

設問1

この攻撃はCL.TE／TE.CL／TE.TEのいずれの分類に該当するか。分類名を答えるとともに、その判定根拠を50字以内で述べよ。

設問1の解答・解説を見る

正解例：

  • 分類：CL.TEスマグリング
  • 判定根拠：フロントエンドは Content-Length を優先し、バックエンドは Transfer-Encoding を優先して境界を解釈しているため（46字）。

解説： フロントエンド（Front）が Content-Length（CL）を、バックエンド（Back）が Transfer-Encoding（TE）を優先するパターンなので「CL.TE」と呼ばれる。この不一致により、フロントエンドが無視した末尾の SMUGGLED がバックエンド側では次リクエストの一部として解釈され、後続利用者のリクエストに紛れ込む「密輸（スマグリング）」が成立する。

解説・採点基準（計15点）：

採点項目キーワード配点
分類名を正しく回答CL.TE5点
判定根拠にフロントエンドがContent-Length優先である旨フロントエンド、Content-Length優先5点
判定根拠にバックエンドがTransfer-Encoding優先である旨バックエンド、Transfer-Encoding優先5点

設問2

この事象が悪用された場合に想定される具体的な被害を2つ挙げよ。また、F社が講じるべき恒久的な対策を、フロントエンド・バックエンド双方の設定変更以外の観点から1つ述べよ。

設問2の解答・解説を見る

正解例：

  • 想定被害：
    1. 攻撃者が細工したリクエストの断片が、別の正規利用者のリクエストに連結され、その利用者へのレスポンスを攻撃者が窃取する（レスポンスの混入・キャッシュ汚染）。
    2. 連結された断片によって認証情報やセッションCookieを含むリクエストが改ざんされ、セッションハイジャックやアクセス制御のバイパスが発生する。
  • 恒久的対策：フロントエンドとバックエンドの間で Content-Length と Transfer-Encoding の両方が指定されたリクエストを拒否する、あるいはフロントエンドで受信したリクエストを正規化（Normalize）してから単一の方式（例：HTTP/2への統一、チャンク方式を使わない）でバックエンドに転送するようゲートウェイの実装・仕様を統一する。

解説： 実害としては、他ユーザ宛のレスポンス内容の窃取（レスポンス分割・キャッシュポイズニング）、リクエストの改ざんによる認可バイパスやセッションハイジャックが代表的である。恒久対策としては、両ヘッダが同時に存在するリクエストの拒否、HTTP/2エンドツーエンド化によるチャンク転送のあいまいさ排除、あるいはフロントエンドでのリクエスト正規化が有効とされる。

解説・採点基準（計15点）：

採点項目キーワード配点
被害1：レスポンス混入/キャッシュ汚染への言及レスポンス窃取、キャッシュポイズニング4点
被害2：セッションハイジャック/認可バイパスへの言及セッションハイジャック、認可バイパス4点
恒久対策に「両ヘッダ同時存在の拒否」または「正規化/HTTP2統一」への言及拒否、正規化、HTTP/2統一7点

重要キーワード

用語説明
HTTPリクエストスマグリングフロントエンドとバックエンドのHTTPメッセージ境界解釈の差異を悪用し、リクエストを密輸する攻撃
CL.TEスマグリングフロントエンドがContent-Length、バックエンドがTransfer-Encodingを優先することで発生する分類
TE.CLスマグリングフロントエンドがTransfer-Encoding、バックエンドがContent-Lengthを優先することで発生する分類
TE.TEスマグリング両者ともTransfer-Encodingを参照するが、ヘッダの難読化により片方が無視することで発生する分類
リクエスト正規化フロントエンドで受信したリクエストの表現を統一し、あいまいさを排除してからバックエンドに転送する対策
キャッシュポイズニングスマグリングにより汚染されたレスポンスがキャッシュされ、他利用者に配信される二次被害

まとめ

  • 午前I視点： 複数のHTTPサーバを経由する構成では、フロントエンドとバックエンドでリクエスト解釈が食い違い得るという前提を理解する
  • 午前II視点： CL.TE・TE.CL・TE.TEの3分類と、それぞれどちらのヘッダが優先されるかの組み合わせを正確に区別できるようにする
  • 午後視点： ログや実験結果から分類を特定する手順、想定被害（レスポンス窃取・キャッシュポイズニング・セッションハイジャック）、正規化やプロトコル統一による恒久対策を具体的に説明できるようにする