HTTPリクエストスモグリング：知っておくべきすべてのこと

HTTPリクエストスモグリングとは?

この表現の文字通りの意味を確認して、その内容を理解してください。

ご存知の通り、HTTPはウェブサイトやアプリで利用されます。ウェブサイトとそのサーバーは、HTTPを介して体系的にリクエストを交換し、通信しています。

しかし、不整合なリクエストはハッカーにとって好機となります。ハッカーはこの弱点を利用して、不正な目的に加え、HTTPリクエストスモグリング攻撃などを行います。記録によれば、この攻撃手法は2005年に初めて成功し、2020年には複数の新たなバリエーションが確認されました。

結果

現代のウェブシステムでは、HTTPリクエストが絶えず交換されることが通信を成立させる要因です。このようにリクエストは連続的に行き来しています。

バランスを保つためには、フロントエンドとバックエンドのサーバーが共にHTTPの規則に従ってリクエストを処理する必要があります。何らかの不整合が生じた場合、ハッカーが2つのサーバーがそれぞれ処理する隙を狙い、改ざんされたリクエストや入力を仕込む可能性があります。これにより攻撃が始まり、ハッカーが重要な情報にアクセスして悪用する結果に繋がります。

‍

この攻撃の最終的な影響

熟練のハッカーの手に渡れば、このスモグリング攻撃は予想を超える被害をもたらす可能性があります。攻撃者は次のような行動を行う恐れがあります:

• コアレベルのセキュリティ対策を突破し、システムへの権限を取得する
• サイトの管理パネルにアクセスする
• 機密性の高いユーザーデータを閲覧または改ざんする
• XSSやSQLインジェクションなど、さらなる攻撃への道筋を作る
• ウェブユーザーのデータやログイン情報を乗っ取る

‍

手法

HTTP経由の攻撃を成功させるための最初の要件は、CLとTEヘッダーを組み合わせることです。この手法により、ハッカーはフロントエンドとバックエンドのサーバーの処理を混乱させ、不整合が生じる状況を作り出します。以下に、この攻撃を実現するための代表的な3つの方法を示します。

CL.TE（Content-Length.Transfer-Encoding）脆弱性

この脆弱性は、フロントエンドサーバーがCLヘッダーの処理を行い、TEヘッダーはバックエンドサーバーが処理することに起因します。以下にサンプルコードを示します。

POST / HTTP/1.2
Host: example-website-url.com
Content-Length: 20
Transfer-Encoding: chunked

 0 

成功

動作の仕組みを見てみましょう:

フロントエンドサーバーはCLヘッダーの入力を確認し、処理すべきストリームの長さが20バイトであることを把握します。

この情報はバックエンドサーバーに渡され、TEヘッダーを読み取り、「chunked」処理が必要であると判断されます。

最初のチャンク（長さ0のもの）が処理され、終了します。

このサーバーは『Succeeded』の後のバイトを、新しいHTTPリクエストの開始と見なすため、処理が行われず残されます。しかし、実際はそうではなく、HTTPリクエストの処理に不整合が生じる結果となります。これにより、攻撃が成功します。

‍

TE.CL（Transfer-Encoding.Content-Length）脆弱性 

‍

この手法では、フロントエンドサーバーがTEヘッダーを処理し、一方でバックエンドサーバーがCLヘッダーの処理を担当します。以下は、この攻撃を行うためのサンプルコードです。

HOST / HTTP/1.2
Host: example-website-url.com
Content-Length: 4
Transfer-Encoding: chunked 

11

COMPROMISED

0

それでは、この手法がどのように成功するか説明します。フロントエンドサーバーがTEヘッダーを処理する際、HTTPリクエストボディはチャンク方式で処理されます。

最初に11バイトのチャンク1が処理され、その後、0バイトのチャンク2が処理されます。

次に、バックエンドサーバーはContent-Lengthヘッダー（4バイト）を検出し、『COMPROMISED』を別のリクエストと見なして処理をスキップします。

‍

TE-TE挙動（Transfer-Encoding）脆弱性

最後に、TE-TE挙動の手法があります。これは、TEヘッダーのみをフロントエンドとバックエンドサーバーに送信する方法で、TEヘッダーが過剰に利用され、いずれかのサーバーがヘッダーの処理を行わなくなるように強制されることから、TEヘッダーの難読化とも呼ばれます。

以下に、いくつかのHTTPリクエストスモグリングのペイロード例を示します。

Transfer-Encoding: ychunked

Transfer-Encoding:  chunked

—————————————

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

—————————————

Transfer-Encoding : chunked

Transfer-Encoding

: chunked

以上の例から、TEヘッダーは実際のHTTP仕様からわずかにずれるだけで、正当なHTTPリクエストに見せかけることが分かります。そのため、多くのサーバー実装ではこれを正規のHTTPリクエストとして受け入れて処理します。

この型の攻撃を実行するためにハッカーが必要とするのは、TEヘッダーの複数のバリエーションを生成する能力のみです。差異が大きいほど、成功率も向上します。

改良版HTTPリクエストスモグリング攻撃

通常のレスポンスの置換

ミドルウェアにキャッシュサーバーが存在する場合にのみ可能なこの攻撃手法は、キャッシュの破損を伴います。対象はキャッシュエントリの一部として保持される不正なレスポンスで、結果としてサービス拒否攻撃の基盤が作られます。

フィルターの回避

これは、セキュリティフィルターを回避しながら、改ざんされたリクエストを直接バックエンドサーバーに転送する手法です。

認証情報の乗っ取り

これは、クエリストリームに小さなクエリ部分を追加し、検証済みのエンドユーザーのクエリが現れるのを待つ手法です。現れた際、ハッカーはその検証済みクエリにアクセスし、最初に追加した小さなクエリ部分に組み込みます。検証済みクエリが悪意のあるクエリと結び付けられるため、プロキシサーバーやロードバランサーは改ざんされたクエリを正当なものと判断して処理します。

‍

予防策と対策

問題が検出された際、迅速かつ実効性のある対策を講じることが、被害を抑えネットワーク、サーバー、クライアント側の資産を守る唯一の方法です。以下に、対策を講じる上で推奨される主な手法を示します。

• 常にHTTPリクエストを監視する

基本的なHTTPリクエストスモグリングの対策は、サーバーとクライアント側のHTTPリクエストを常に監視することです。監視が行き届けば検出が早くなり、被害も小さくなります。しかし、バックエンドサーバー管理に欠かせないロードバランサーが遠隔地に配置される場合もあるため、100%の実現は困難であることを理解する必要があります。

もし、HTTPリクエストの処理状況を把握するために異なるプラットフォームを用いて2つのサーバーを管理している場合でも問題ありません。両者の解釈の仕方と適切な組み合わせに注目してください。

• パフォーマンス最適化を無効にする

バックエンドの設定変更は必ずしも推奨されるわけではありませんが、CLとTEヘッダーに関連する最適化機能を無効にすることは重要です。これによりウェブシステムのパフォーマンスが多少低下する可能性はありますが、HTTPリクエストスモグリング対策としては迅速な解決策となります。

• ロードバランサーやプロキシサーバーなどのリソース利用を減らす

適切に管理されない場合、これらのツールはハッカーが悪用する手助けとなります。そのため、ウェブシステムにとって非常に必要でない限り、これらのツールの利用は控えるべきです。

• WAFの導入

質の高いWAFは、トラフィックをフィルタリングし、不正なリンクやコードがウェブサイトに到達するのを防ぐため、ウェブサイトにとって欠かせない存在です。

• HTTPログを認証されていないユーザーに公開しない

HTTPログが安全に保護され、認証済みのユーザーのみがアクセスできる状態にあることを確認してください。可能であれば、ユーザー認証も適用してください。

‍

Wallarmはどのようにこの攻撃を阻止できるか?

本記事を通じて、HTTPリクエストスモグリングがあらゆるウェブサイト運営者にとって懸念事項であることがお分かりいただけたと思います。このため、Wallarmは本攻撃を抑制し、関連するリスクを防ぐための多様な対策を備えた包括的なウェブセキュリティソリューションを提供しています。

1. GoTestWAFは、ウェブサイト保護の革新的な手法です。既設のWAFの有用性を確認できるオープンソースツールで、最先端の検知技術が使用されています。動作するWAFのみがウェブサイトを守ることを保証し、セキュリティを一層強化します。また、『HTTPリクエストスモグリングのテスト方法』の解明にも役立ちます。
2. 高性能なCloud WAF、または Cloud Web Application Firewall は、ウェブサイトに送られるトラフィックを確実に守ります。誤検知がほとんどなく、OWASP Top 10の脅威からウェブサイトを保護することを約束します。特筆すべきは、ライブラリ検知やバイパス耐性を含む卓越した検知技術にあります。
3. API Security Platformは、ウェブAPIを守るための先進的な手法です。RESTやSOAPなど主要なAPIに対応しているため、安心して導入できます。脅威検知から早期対応まで、すべてのAPIエンドポイントを確実に保護します。

Wallarmを試し、HTTPリクエストスモグリングによるOWASPの脅威から貴社のウェブサイトを守ってください。（まずは無料トライアルがおすすめです。）