HTTPリクエストスマグリングとは？攻撃例やおすすめの対策を解説

HTTPリクエストスマグリングは、近年注目を集めている重大なWebアプリケーションの脆弱性です。この攻撃手法は、フロントエンドサーバーとバックエンドサーバーの間でHTTPリクエストの解釈に違いが生じることを悪用し、攻撃者にさまざまな悪意ある行動を可能にします。

本記事では、HTTPリクエストスマグリングの仕組みや種類、攻撃例について詳しく解説。また、この脆弱性を見つける方法や、効果的な対策についても説明します。Webアプリケーションのセキュリティを守るために、開発者や管理者の人はぜひ参考にしてください。

HTTPリクエストスマグリングとは？

HTTPリクエストスマグリングは、高速化のためにフロントエンドサーバーとバックエンドサーバーに分かれたWebシステムで発生する脆弱性です。この脆弱性が存在すると、他の利用者の情報が漏えいしたり、ローカル環境の管理画面にアクセスできるなどの深刻な影響が生じる可能性があります。また、再現が難しいため、脆弱性診断でも見逃されがちです。

HTTPリクエストスマグリングは能動的攻撃と受動的攻撃の両方の性質を持ちます。まず、攻撃者は問題のあるWebシステムに罠を仕掛けます（能動的攻撃）。

次に、キャッシュ汚染などが起きた際、そのタイミングでアクセスした利用者の情報が奪われます（受動的攻撃）。クラウド上でWebシステムを構築する場合、フロントエンドとバックエンドを分ける必要があり、対策を怠るとHTTPリクエストスマグリングの脆弱性が混入する恐れがあります。そのため、適切な対策を講じることが重要です。

リクエストスマグリングの仕組み

以下は、フロントエンドサーバーとバックエンドサーバーで構築されたWebシステムにおける通常の処理の例です。

1. フロントエンドサーバーで各利用者のHTTPリクエストを受け付ける
2. フロントエンドサーバーが受け付けたHTTPリクエストを解釈し、バックエンドサーバーに転送する
3. バックエンドサーバーは転送されてきたHTTPリクエストを受理し、それぞれに適した処理を実行する

このように、フロントエンドサーバーで一旦HTTPリクエストを受け付けてからバックエンドサーバーに転送する構成をとることで、システム全体の拡張性が高まります。

フロントエンドサーバーを増やせば同時に受け付けられるHTTPリクエストの上限が上がり、バックエンドサーバーを増やせば同時に処理できる上限が上がるなど、柔軟な拡張が可能に。

HTTPリクエストスマグリングの脆弱性が発生する原因は、フロントエンドサーバーとバックエンドサーバーがHTTPリクエストヘッダ、特に「Content-Length」ヘッダと「Transfer-Encoding」ヘッダの解釈方法に違いがあることに起因します。

この2つのヘッダは、HTTPリクエストの本文の長さを示すために使用されますが、それぞれの動作は微妙に異なります。フロントエンドサーバーとバックエンドサーバーがこれらのヘッダの扱い方を異なる方式で実装していると、攻撃者はその違いを利用してマルウェアを仕込んだり、他者の情報を不正に入手したりできてしまうのです。

こうした深刻な脆弱性を防ぐためには、ヘッダの解釈ルールを統一することが重要です。さらに、HTTPリクエストを受け渡しするフロントエンドとバックエンドの間に、ヘッダチェック機能を設けるなどの対策も有効でしょう。

リクエストスマグリングの種類

HTTPリクエストスマグリングには、主に以下の3種類があります。いずれの種類も、フロントエンドサーバーとバックエンドサーバーが HTTPリクエストヘッダの解釈方法を正しく同期していないことに起因する脆弱性です。攻撃者はこの違いを利用して、マルウェアの仕込みや情報漏えいなどの攻撃を実行できてしまいます。

• TE:CL
• CL:TE
• TE:TE

これらはそれぞれ、Transfer-EncodingとContent-Lengthヘッダの優先順位が異なることに基づく攻撃を指しています。

TE:CL

この種類の攻撃では、フロントエンドサーバーが Transfer-Encoding ヘッダを優先し、バックエンドサーバーが Content-Length ヘッダを優先する違いを利用します。

攻撃者は Transfer-Encoding: chunked と Content-Length: 異なる値 を設定したリクエストを送信します。フロントエンドは Transfer-Encoding を優先してボディを処理しますが、バックエンドは Content-Length を優先するため、2つのサーバーで異なるリクエストボディを解釈してしまいます。

CL:TE

この種類は、TE:CLリクエストスマグリングとは逆のケースです。フロントエンドサーバーが Content-Length を優先し、バックエンドサーバーが Transfer-Encoding を優先する違いを利用します。

攻撃者は Content-Length: 異なる値 と Transfer-Encoding: chunked を設定したリクエストを送信。フロントエンドは Content-Length を優先してボディを処理し、バックエンドは Transfer-Encoding を優先するため、リクエストボディの解釈が異なります。

TE:TE

この種類の攻撃では、フロントエンドサーバーとバックエンドサーバーの両方が Transfer-Encoding ヘッダを優先するものの、ヘッダの解釈方法が異なることを利用します。

攻撃者は複数の Transfer-Encoding ヘッダを設定したリクエストを送信。フロントエンドとバックエンドで Transfer-Encoding ヘッダの扱いが異なるため、リクエストボディの解釈が異なってしまいます。

リクエストスマグリングの攻撃例

リクエストスマグリング攻撃は、Webアプリケーションのセキュリティを脅かす深刻な脅威です。本章では、リクエストスマグリング攻撃の3つの主要な手法について詳しく解説します。

• Webキャッシュポイズニング
• オンサイトリダイレクト
• フロントエンドセキュリティの回避

Webキャッシュポイズニング

Webキャッシュポイズニング攻撃では、攻撃者はWebアプリケーションのキャッシュ機能を悪用して、キャッシュサーバーが悪意のあるコンテンツを保持するように仕向けます。

これにより、攻撃者はユーザーに偽のコンテンツを提供し、情報を改ざんしたり機密情報を盗んだりできます。

オンサイトリダイレクト

オンサイトリダイレクト攻撃では、攻撃者は脆弱なリダイレクト機能を悪用して、正当なユーザーがリクエストを送信するときに、攻撃者が指定したサイトにリダイレクトするように仕向けます。

これにより、攻撃者はユーザーを悪意のあるサイトに誘導し、フィッシングやマルウェアの配布などの悪意ある行動を行うことが可能です。

フロントエンドセキュリティの回避

リクエストスマグリング攻撃におけるフロントエンドセキュリティの回避は、攻撃者がさまざまな手法を用いて、Webアプリケーションのセキュリティ対策をかいくぐり、攻撃を行います。

具体的には、JavaScriptの無効化や回避、セキュリティヘッダーの無視、CORSの悪用、そしてユーザー操作の模倣などです。

これらの手法を通じて、攻撃者はWebアプリケーションのセキュリティメカニズムを迂回し、悪意を持ってリクエストを改ざんしたり、不正な操作を行ったりすることが可能になります。

リクエストスマグリングの見つけ方

リクエストスマグリングの攻撃パターンを特定するためのさまざまな手法があります。

• 攻撃パターンの特定
• レスポンスの比較
• プロキシツールの使用
• セキュリティヘッダーの監視
• ログの分析
• 定期的な脆弱性スキャン
• 統合セキュリティソリューションの使用

攻撃パターンの特定

リクエストヘッダーやボディに特定のパターンを含むリクエストを探し、異常な振る舞いを検知します。

レスポンスの比較

攻撃を行う前後のリクエストのレスポンスを比較し、挙動の違いを検出します。

プロキシツールの使用

プロキシツールを介してトラフィックを監視し、不正なリクエストやレスポンスを検出します。

セキュリティヘッダーの監視

セキュリティヘッダーの変更や欠落を監視し、不正な操作を検知します。

ログの分析

Webサーバーやアプリケーションのログを分析し、異常なリクエストやアクセスを検出します。

定期的な脆弱性スキャン

定期的にWebアプリケーションを脆弱性スキャナーでスキャンし、リクエストスマグリングの脆弱性を特定します。

統合セキュリティソリューションの使用

統合セキュリティソリューションを導入し、リアルタイムでトラフィックを監視して攻撃を検知します。

リクエストスマグリングの有効な対策

本章では、リクエストスマグリングの有効な対策として、「パッチのアップデートを行う」「フロントエンドとバックエンドで同じサーバーを使用する」「バックエンドサーバーの通信にHTTP/2を使用する」「WAFを使用する」ことを解説します。

• パッチのアップデートを行う
• フロントエンドとバックエンドで同じサーバーを使用する
• バックエンドサーバーの通信にHTTP/2を使用する
• WAFを使用する

パッチのアップデートを行う

リクエストスマグリング攻撃への対策として、パッチのアップデートは重要な手法の一つです。パッチのアップデートは、Webアプリケーションやその依存関係、使用しているサーバーソフトウェアなどの脆弱性やセキュリティホールを修正するために有効です。

具体的には、リクエストスマグリング攻撃はWebアプリケーションやその周辺のソフトウェアに存在する脆弱性を悪用して行われることがあります。このような脆弱性は、通常、ソフトウェアの開発者やベンダーによって見つかり、修正されたパッチがリリースされます。

したがって、リクエストスマグリング攻撃への対策として、システム管理者や開発者は定期的にパッチを確認し、システムやソフトウェアを最新の状態に保つ必要があります。これにより、既知の脆弱性が修正され、攻撃者がそれらを悪用する可能性が低くなるでしょう。

また、パッチのアップデートにはリスクが伴う場合があります。アップデートがシステムの動作に影響を与えたり、互換性の問題を引き起こしたりする可能性があるため、アップデートを行う前にテストや検証を行うことが重要です。さらに、重要なシステムやデータにはバックアップを取得し、災害復旧計画を構築しておくことも推奨されます。

つまり、パッチのアップデートはリクエストスマグリング攻撃への効果的な対策の一つであり、セキュリティ意識の向上や定期的なシステムの監査と組み合わせて実施されるべきです。

フロントエンドとバックエンドで同じサーバーを使用する

HTTPリクエストの終端を統一するために、フロントエンドとバックエンドで同じWebサーバーアプリケーションを使用することは、効果的な手法の一つです。この手法は、フロントエンドとバックエンドの間でのリクエストの処理方法や終端条件を一貫させることで、リクエストの境界を明確にし、HTTPリクエストスマグリング攻撃の可能性を軽減します。

具体的には、同じWebサーバーアプリケーションを使用することで、リクエストの処理方法やパス方法が統一。これにより、リクエストの終端条件が一致し、攻撃者がリクエストスマグリング攻撃を行う際に混乱を招く可能性が低くなります。

また、同じWebサーバーアプリケーションを使用することで、フロントエンドとバックエンドの間での通信プロトコルやヘッダーの取り扱いが一致するため、リクエストの解釈が一貫して行われます。これにより、攻撃者がリクエストの改ざんや混乱を利用して攻撃しにくくなるでしょう。

ただし、この手法を採用する際には、フロントエンドとバックエンドの開発者が協力して、同じWebサーバーアプリケーションを適切に設定し、運用する必要があります。また、アプリケーションの構成や要件に応じて、適切なセキュリティ対策を講じることも重要です。

バックエンドサーバーの通信にHTTP/2を使用する

HTTP/2は、従来のHTTPプロトコルに比べて大幅な改善が行われたバージョンです。従来のHTTPでは、一つの接続で一つのリクエストしか処理できません。そのため、複数のリクエストを処理するには、新しい接続を確立する必要がありました。

このリクエスト間の切り替えが発生する際に、フロントエンドサーバーとバックエンドサーバーの間でリクエストの境界線が曖昧になる可能性があります。これがHTTPリクエストスマグリングの脆弱性を生む一因となっていました。

一方、HTTP/2では、一つの接続で複数のリクエストを同時に処理できるようになりました。これにより、リクエスト間の切り替えが減少し、リクエストの境界線が明確になります。さらにHTTP/2には、フレームという単位でデータを送受信する仕組みが導入されました。このフレームには、それぞれヘッダ情報が含まれているため、リクエストの区切りがより明確になっています。

このように、HTTP/2ではリクエスト間の境界が曖昧になる可能性が大幅に減少しています。そのため、HTTPリクエストスマグリングのような脆弱性を悪用した攻撃は困難になります。攻撃者がスマグリング攻撃を仕掛けようとしても、フロントエンドサーバーとバックエンドサーバーの両方でリクエストが同じように解釈されるため、攻撃は成功しません。

したがって、HTTP/2プロトコルを採用することで、Webアプリケーションのセキュリティを大きく向上できます。特に、フロントエンドサーバーとバックエンドサーバーの分離構成を取るシステムにおいては、HTTP/2の導入が強く推奨されます。HTTPリクエストスマグリングのリスクを回避するだけでなく、同時並行処理によるパフォーマンス向上も期待できるためです。ただし、HTTP/2の導入には、サーバーソフトウェアやミドルウェアなどの準備が必要となるため、既存システムへの影響も検討しなければなりません。

WAFを使用する

Webアプリケーションファイアウォール（WAF）を導入することは、Webサイトを保護する有力な手段の一つです。WAFは、さまざまな攻撃からWebアプリケーションを守るためのセキュリティ製品であり、通常は脆弱性や攻撃パターンを検知し、それらに対して適切な対策を講じます。しかし、WAFを導入し運用するには一定の費用がかかります。

さらに、適切なチューニングが行われていない場合、WAFだけではHTTPリクエストスマグリング攻撃を防ぐことができません。そのため、WAFを導入する際は、適切な設定や定期的な監視が必要です。WAFは、他のセキュリティ対策が実装できない場合や、追加の安全層として検討されるべきです。

まとめ

リクエストスマグリングは、攻撃者がリクエストの境界を曖昧にし、フロントエンドとバックエンドの間でリクエストをスマグリングすることで、さまざまな悪意のある行動を可能にする重大な攻撃手法です。

この攻撃から守るには、入力検証やセキュリティヘッダーの適切な設定、脆弱性スキャン、監視などの対策が必要不可欠です。さらに、リクエストとレスポンスの分析やプロキシツール使用、セキュリティヘッダー監視などにより、攻撃を検知する必要があります。

セキュリティ意識を持ち、定期的な監査やアップデートを行うことで、リスクを最小化し、安全なWebアプリケーションを実現しましょう。