うつろい EC は AWS ALB(フロントエンド)→ Apache/PHP(バックエンド)構成で、フロントは Content-Length を、バックエンドは Transfer-Encoding を採用する Quirk を持つ古い構成。両者の境界解釈が違うため、CL.TE 攻撃が成立する状態。
このラボは概念のシミュレータです。実際の HTTP プロキシの挙動を JS で模擬し、smuggling リクエストがどう「分割される」かを見せます。
舞台
Mission
下のリクエストを送ると、フロントは「1リクエスト」と認識する一方、バックエンドは「2リクエスト」と解釈します。後続のユーザリクエストがバックエンドの「2番目のリクエストの本文」と結合される現象を観察してください。
攻撃リクエスト(CL.TE)
プロキシ・バックエンドそれぞれの解釈
① フロントエンド(ALB)— Content-Length 採用
(まだ受信していません)
② バックエンド(Apache)— Transfer-Encoding 採用
(まだ受信していません)
何が起きているか — シミュレーター解説
CL.TE のメカニズム
フロント: Content-Length: 13 を採用 → 空行から 13 バイトを「1つの本文」と認識
"0\r\n\r\nSMUGGLED" の13バイト = 1リクエスト終了
バックエンド: Transfer-Encoding: chunked を採用
→ "0\r\n\r\n" でチャンク終端、そこでリクエスト1終了
→ その後の "SMUGGLED" は「次のリクエストの開始」と解釈
結果:バックエンドのキューに「SMUGGLED」(中途半端なリクエスト)が残る
↓
次に来る正規ユーザのリクエストが、この中途半端なリクエストの続きとして「結合」される
↓
正規ユーザの Authorization、Cookie 等のヘッダが、攻撃者リクエストの本文に混入する
必要な前提知識
サイト側の対策