実演動画あり！HTTPリクエスト・スマグリング（HRS）とは？
目次
HTTPリクエスト・スマグリング（HRS）とは？
HTTPリクエスト・スマグリング（HTTP Request Smuggling、略称、HRS）とは、おもに高速化のためにフロントエンドサーバーとバックエンドサーバーに分かれて構築されたWebシステムで発生する問題です。
このHTTPリクエスト・スマグリング(HRS)が存在した場合、他利用者の情報が漏洩する、あるいはローカル環境上の管理画面へのアクセスできるなど様々な影響をシステムに与えることが特徴です。また、脆弱性を再現することが難しい傾向にあるため、脆弱性診断サービスなどを実施しても見逃してしまう可能性が高いことも特徴として挙げられます。
なお、HTTPリクエスト・スマグリング(HRS)は能動的攻撃と受動的攻撃の両方の性質を併せ持っています。罠を仕掛ける対象が問題のあるWebシステムであるため、罠を仕替えるまでが能動的攻撃となり、キャッシュ汚染などが起きた場合に、そのタイミングでアクセスしてきた利用者の情報が奪われるため、この部分が受動的攻撃にあたると言えます。
近年ではクラウド上でWebシステムを構築するケースが増えていますが、クラウドサービスによっては上記のようなフロントエンドとバックグランドで分けてシステムを構築することが必須になっている場合があるため、対策を行わずに構築してしまうとHTTPリクエスト・スマグリング(HRS)の問題が混入してしまうため注意が必要です。
HTTPリクエスト・スマグリング(HRS)攻撃の仕組み
以下はフロントエンドサーバーとバックエンドサーバーで構築されたWebシステムにおける通常の処理の例となります。
通常の処理の例
- フロントサーバーで各利用者のHTTPリクエストデータを受け付ける
- フロントサーバーで受け付けたHTTPリクエストをフロントエンドが解釈した後にバックエンドサーバーに転送する
- バックグランドサーバーは転送されてきたHTTPリクエストを受理して、それぞれに適した処理を実行する
上記のようにフロントエンドサーバーで一旦、HTTPリクエストを受理してから、バックエンドサーバーに転送する構成をとることでシステム全体の拡張性が高くなります。例えばフロントエンドサーバーを増やすことで同時に受け付けることのできるHTTPリクエストの上限を挙げる、あるいはバックエンドサーバーを増やすことで同時に処理できる処理数の上限を挙げるなどの拡張が可能になります。
しかし気をつけなくてはならないのが、例えばフロントエンドサーバーとバックエンドサーバーとの間でHTTPリクエストヘッダの解釈の仕方に齟齬ができてしまった場合、以下のような問題が発生します。
HTTPリクエスト・スマグリング攻撃の例
- 攻撃者は通常のHTTPリクエストに攻撃ペイロードを付与して送信する
- フロントエンドサーバーでHTTPリクエストを受け付ける
- フロントエンドサーバーで受け付けたHTTPリクエストをバックエンドサーバーに転送する
- 攻撃者のペイロードが利用者のHTTPリクエストに干渉して別のHTTPリクエストとして解釈される
上記のように攻撃者の送信したペイロードによって、フロントエンドサーバーとバックエンドサーバーとの間でHTTPリクエストの解釈の仕方に齟齬が発生してしまうと、他の利用者のリクエストに干渉して異なる処理をバックエンドサーバーに実行させてしまう現象が発生します。
このような問題をHTTPリクエスト・スマグリング脆弱性と呼び、この脆弱性を狙った攻撃をHTTPリクエスト・スマグリング攻撃と呼びます。
脆弱性の解説動画
HTTPリクエスト・スマグリング(HRS)が起こる原因
HTTPリクエスト・スマグリング（HRS）は、フロントエンドサーバーとブックエンドサーバーの間で、以下のHTTPヘッダの解釈の優先度に差異があることで発生します。
Content-Length
HTTPの転送エンコーディングの1つで、送信するデータ量が予め分かっている場合に使用されるHTTPリクエストヘッダとなります。
【Content-Lengthヘッダの例】
POST / HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingTransfer-Encoding
HTTPの転送エンコーディングの1つで、転送開始時で送信データ量がわからない場合に使用されます。データをチャンクというブロックに区切って転送します。
【Transfer-Encodingヘッダの記載例】
Transfer-Encoding: chunked
データ量（16新数）
送信データ=値
終端（0）HTTPリクエストヘッダに「Transfer-Encoding: chunked」を挿入した上で、16進数でデータ量と改行を挟んで転送データを付与します。また転送データが終わる際には、「0」を挿入してデータの終了を通信先に伝えます。
【Transfer-Encodingヘッダの例】
POST / HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
3
x=1
b
q=smuggling
c
q=smuggling1
d
q=smuggling11
0CL・TEタイプのHTTPリクエスト・スマグリング(HRS)攻撃
フロントエンドサーバーが「Content-Length」ヘッダ、バックエンドサーバーが「Transfer-Encoding」ヘッダを優先して解釈している場合に起きます。
【攻撃パケットの例】
POST / HTTP/1.1
Host: example.com
Content-Length: 41
Transfer-Encoding: chunked
0
GET /mypage HTTP/1.1
Host: evil.com上記のような攻撃パケットが送信された場合、フロントエンドサーバーでは、以下のようにHTTPリクエストが解釈されて転送します。
【フロントエンドサーバーの解釈するHTTPリクエストの例】
POST / HTTP/1.1
Host: example.com
Content-Length: 41
Transfer-Encoding: chunked
0
GET /mypage HTTP/1.1
Host: evil.comしかしバックエンドサーバーでは「Transfer-Encoding」ヘッダを優先するため、転送されてきたHTTPリクエストが分割して解釈されます。
【バックエンドサーバーの解釈するHTTPリクエストの例1】
POST / HTTP/1.1
Host: example.com
Content-Length: 41
Transfer-Encoding: chunked
0【バックエンドサーバーの解釈するHTTPリクエストの例2】
GET /mypage HTTP/1.1
Host: evil.comこのためバックエンドサーバーでは分割されたHTTPリクエストが別のHTTPリクエストに干渉を引き起こして問題が発生します。
TE・CLタイプのHTTPリクエスト・スマグリング(HRS)攻撃
フロントエンドサーバーが「Transfer-Encoding」ヘッダ、バックエンドサーバーが「Content-Length」ヘッダを優先して解釈している場合に起きます。
【攻撃パケットの例】
POST / HTTP/1.1
Host: example.com
Content-Length: 3
Transfer-Encoding: chunked
40
POST /mypage HTTP/1.1
Host: evil.com
Content-Length: 4
x=1
0上記のような攻撃パケットが送信された場合、フロントエンドサーバーでは以下のデータが決まったサイズのPOSTデータとして解釈されて転送されます。
【フロントエンドサーバーの解釈するHTTPリクエストの例】
POST / HTTP/1.1
Host: example.com
Content-Length: 3
Transfer-Encoding: chunked
40
POST /mypage HTTP/1.1
Host: evil.com
Content-Length: 4
x=1
0しかしバックエンドサーバーでは「Transfer-Encoding」ヘッダを優先するため、転送されてきたHTTPリクエストが分割して解釈されます。
【バックエンドサーバーの解釈するHTTPリクエストの例1】
POST / HTTP/1.1
Host: example.com
Content-Length: 3
Transfer-Encoding: chunked
40【バックエンドサーバーの解釈するHTTPリクエストの例2】
POST /mypage HTTP/1.1
Host: evil.com
Content-Length: 4
x=1
0こちらに関しても攻撃パケットが複数のHTTPリクエストとしてバックエンドサーバーで解釈されるため、別のHTTPリクエストに干渉を引き起こして問題が発生します。
HTTPリクエスト・スマグリング(HRS)攻撃への対策手法
以下の必須対策を実施することで、HTTPリクエスト・スマグリング（HRS）攻撃を防止することができます。
必須対策
HTTPの仕様上、「Content-Length」ヘッダと「Transfer-Encoding」ヘッダは両立することはできないため、仮に両方のヘッダが付与されていた場合は、「Content-Length」ヘッダを優先するということになっています。
しかし現実的にネットワーク機器やソフトウェアによっては仕様通りに構築されていないことがあるがあるため、利用するサーバー類の設定変更などを行いフロントエンドサーバーとバックエンドサーバーの「Content-Length」ヘッダと「Transfer-Encoding」ヘッダの解釈を合わせることでHTTPリクエスト・スマグリング攻撃を防止することができます。
オプショナルな対策（WAFの導入）
Webアプリケーションファイアーウォール（WAF）と呼ばれる製品を導入して、Webサイトを保護する方法です。この方法は一定の防御効果が見込めますが、製品を導入・運用していくのに費用が掛かることに加えて、適切なチューニングを行なっていないとHTTPリクエスト・スマグリング攻撃を防御することができません。そのため、あくまで前述した対策が実施できない場合などに代価案として実施することが望ましい対策と言えます。
まずは手軽にツールで脆弱性診断
上述の対策手法が重要となる一方で、脆弱性診断を通じて脆弱性が混入されていないかを検知する事も重要となります。
脆弱性診断とは何かについて詳しく知りたい⽅は脆弱性診断とは(エンジニア向け)と脆弱性診断とは(⾮エンジニア向け)もぜひご参照ください。
脆弱性検知やセキュリティレベルを強化したい企業様はぜひ弊社の脆弱性診断ツール「Securify Scan」を活用ください。
無償でのトライアル実施も行っておりますので、お気軽にお問い合わせください。
