リクエストスマグリング
フロントエンドのプロキシとバックエンドのサーバの 2 段構成に，次の HTTP 要求が届いた。フロントエンドが Content-Length を，バックエンドが Transfer-Encoding を優先してメッセージ境界を解釈する場合に起こり得ることとして，適切なものはどれか。
POST / HTTP/1.1
Host: www.example.com
Content-Length: 6
Transfer-Encoding: chunked
0
G- ア2 つの機器が同じ長さで本文を区切るので境界のずれは生じず，要求が分割されることはない。
- イTransfer-Encoding と Content-Length が両方ある場合，RFC 9112 は Content-Length を優先すると定めているので，両者とも同じ解釈になる。
- ウこの攻撃は通信を TLS で暗号化すれば，要求が改ざんされなくなるため防止できる。
- エ2 つの機器が本文の終端を食い違って解釈するため，一方が本文の一部とみなした残りのバイトが次の要求の先頭として扱われ，後続の要求に不正な内容を紛れ込ませられる。
正解と解説を見る
正解 エ
この問題の基礎知識
- HTTP/1.1 の本文の長さは，Content-Length（バイト数）か Transfer-Encoding: chunked（チャンクの長さと内容を繰り返し，長さ 0 のチャンクで終わる）で示される。
- 持続的接続では 1 本の TCP 接続で複数の要求が続けて送られるので，本文の終端をどこと解釈するかによって，次の要求がどこから始まるかが決まる。プロキシとバックエンドの間の接続は，複数の利用者の要求で共用されることがある。
- HTTP リクエストスマグリングは，中継する機器と後段の機器でメッセージの境界の解釈が食い違うことを利用し，後続の要求に攻撃者の内容を紛れ込ませる攻撃である。
- RFC 9112 では，Transfer-Encoding と Content-Length が両方ある場合は Transfer-Encoding が優先され，そのようなメッセージはエラーとして扱うべきとされる。
ア2 つの機器が同じ長さで本文を区切るので境界のずれは生じず，要求が分割されることはない。
前提どおり優先するヘッダが機器ごとに異なれば本文の終端の解釈もずれる。両者が常に同じ解釈をするという誤りで，スマグリングの成立条件を取り違えている。
イTransfer-Encoding と Content-Length が両方ある場合，RFC 9112 は Content-Length を優先すると定めているので，両者とも同じ解釈になる。
RFC 9112 では両方ある場合は Transfer-Encoding が優先されるので，向きが逆である。そもそもスマグリングは，問題文の前提のように機器ごとに優先するヘッダが異なるという実装の食い違いを突く攻撃である。
ウこの攻撃は通信を TLS で暗号化すれば，要求が改ざんされなくなるため防止できる。
スマグリングは正規の経路で送られた要求を機器間の解釈差で悪用する攻撃で，経路の暗号化とは無関係である。TLS は境界解釈の不一致を解消しない。
エ2 つの機器が本文の終端を食い違って解釈するため，一方が本文の一部とみなした残りのバイトが次の要求の先頭として扱われ，後続の要求に不正な内容を紛れ込ませられる。正解
フロントエンドは Content-Length の 6 バイトを本文として転送するが，バックエンドは長さ 0 のチャンクで本文が終わったと解釈する。残った「G」は次の要求の先頭として扱われ，後続の要求に攻撃者の内容が紛れ込む（CL.TE 型のスマグリング）。
検証用の出典出典照合済み
RFC 9112 HTTP/1.1 Section 6.3 ／ CWE-444 Inconsistent Interpretation of HTTP Requests照合の根拠（6 件）
- エ（正解）: 両ヘッダの併存はスマグリングの試みを示し得るのでエラーとして扱うべき。イ（誤り）: 両方ある場合は Transfer-Encoding が Content-Length を上書きする
If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 11.2) or response splitting (Section 11.1) and ought to be handled as an error.
RFC 9112 · Section 6.3（新しいタブで開きます） - エ（正解）: Content-Length はその値のオクテット数を本文の長さとする。これを優先するフロントエンドは 6 バイト（"0\r\n\r\nG"）全部を本文として転送する
If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets.
RFC 9112 · Section 6.3（新しいタブで開きます） - エ（正解）: チャンク形式は長さ 0 のチャンクと空行で終わる。Transfer-Encoding を優先するバックエンドは "0\r\n\r\n" で本文が終わったと解釈し，残りの "G" を次の要求の先頭として扱う
The chunked transfer coding is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer section, and finally terminated by an empty line.
RFC 9112 · Section 7.1（新しいタブで開きます） - エ（正解）・ア（誤り）: 受信者間の解析の違いを突いて，無害に見える要求の中に別の要求を紛れ込ませる。前提どおり優先するヘッダが異なれば境界はずれる
Request smuggling ([Linhart]) is a technique that exploits differences in protocol parsing among various recipients to hide additional requests (which might otherwise be blocked or disabled by policy) within an apparently harmless request.
RFC 9112 · Section 11.2（新しいタブで開きます） - ア（誤り）: TE と CL が異なる要求では機器間で扱いの食い違いが生じ得る
For example, discrepancies can arise in how to handle duplicate headers like two Transfer-encoding (TE) or two Content-length (CL), or the malicious HTTP message will have different headers for TE and CL.
CWE-444 · Extended Description（新しいタブで開きます） - ウ（誤り）: SSL/TLS に対応したプロキシでもスマグリングは起こり得る。原因は解釈の不一致で，通信路の暗号化では解消しない
SSL/TLS-capable proxy allows HTTP smuggling when used in tandem with HTTP/1.0 services, due to inconsistent interpretation and input sanitization of HTTP messages within the body of another message
CWE-444 · Observed Examples (CVE-2022-24766)（新しいタブで開きます）
検算: 本文 "0\r\n\r\nG" は 6 バイトで Content-Length: 6 と一致する。フロントエンド（CL 優先）は 6 バイト全部を本文として転送し，バックエンド（TE 優先）は長さ 0 のチャンク "0\r\n\r\n" で本文を終えるので，残りの "G" が次の要求の先頭になる（CL.TE 型）。