HTTPリクエスト密輸攻撃、それを回避する方法と危険

ユーザーがインターネットを閲覧してさまざまなタスクを実行すると、攻撃を受ける可能性があります。 サイバー犯罪者は、その利益を得るために、オペレーティングシステムの脆弱性と欠陥を探します。 したがって、更新されたオペレーティングシステムと優れたウイルス対策を用意することは、常に防御の基礎となる優れた出発点です。 ただし、サイバー犯罪者の標的はインターネットユーザーだけではありません。 また、Webサーバーに対して攻撃を実行します。 ファイアウォール、プロキシサーバーなど。 今日は後者に影響を与えるタイプの攻撃について話します。 このチュートリアルでは、何について話します HTTPリクエストの密輸は また、なぜそれがとても危険なのかについても説明します。

HTTPリクエスト密輸攻撃

この攻撃は何をするのか、そして危険

We HTTPリクエストスマグリング攻撃を定義できます そのXNUMXつとして、分析の不一致を利用して、XNUMXつ以上のHTTPデバイス/エンティティがユーザーとWebサーバー間のデータフローにある場合。 XNUMX人以上のユーザーから受信したHTTPリクエストのストリームをWebサイトが処理する方法を妨げる手法に遭遇しました。

これらの脆弱性は本質的に重大であることが多く、サイバー犯罪者がセキュリティ制御を回避し、個人データへの不正アクセスを取得し、アプリケーションの他のユーザーを直接侵害することさえ可能にします。 このHTTPリクエストの違法なトラフィックにより、キャッシュポイズニング、セッションハイジャックなどのさまざまな攻撃が可能になり、Webアプリケーションのファイアウォール保護をバイパスする機能も得られます。

このHTTPリクエストスマグリング攻撃は、さまざまなコンピューターやサービスに影響を与える可能性があります。

  • Webサーバー。
  • ファイアウォール。
  • プロキシサーバー。

起源については、この攻撃がKlein、Ronen Heled、Chaim Linhart、SteveOrrinなどのWatchfire研究者のグループによって実証された2005年にさかのぼります。 ただし、近年、攻撃対象領域を拡大し、内部APIおよびキャッシュポイズニングへの最大の特権アクセスを可能にする多くの改善が行われています。

この攻撃がどのように発生するか

今日のWebアプリケーションは、ユーザーと最終的なアプリケーションロジックの間でHTTPサーバー文字列を頻繁に使用します。 このようにして、ユーザーはフロントエンドサーバーにリクエストを送信し、次にフロントエンドサーバーがXNUMXつ以上のバックエンドサーバーにリクエストを送信します。 クラウドベースのアプリケーションのように、このアーキテクチャはより頻繁になり、場合によっては避けられないことに注意する必要があります。

フロントエンドサーバーがHTTPリクエストをバックエンドサーバーに転送する場合、通常、同じバックエンドネットワーク接続を介して複数のリクエストを送信します。 これは、より効率的でより高いパフォーマンスを提供するために行われます。 動作の方法は単純です。最初にHTTPリクエストが次々に送信されます。 次に、受信サーバーは各HTTP要求のヘッダーを解析して、XNUMXつの要求がどこで終了し、次の要求がいつ開始するかを判別します。

非常に重要な側面は、 フロントエンドおよびバックエンドシステム しなければなりません リクエストの制限に同意する 。 そうしないと、サイバー犯罪者がフロントエンドシステムとバックエンドシステムにあいまいな要求を送信し、それを異なる方法で理解する可能性があるため、これは関連性があります。

ここで、攻撃者はフロントエンド要求の一部をバックエンドサーバーによって次の要求の開始として解釈させます。 次に何が起こるかというと、それは次の要求に先行し、アプリケーションがその要求を処理する方法に干渉を引き起こします。 HTTPリクエストスマグリング攻撃が発生し、そのサーバーの所有者に悲惨な結果をもたらす可能性があります。

これらの攻撃が発生する理由

HTTP仕様では、リクエストの終了場所を指定するXNUMXつの異なる方法が提供されているため、HTTPリクエストスマグリングの脆弱性の大部分が発生します。 ヘッダーは単純で、メッセージ本文の長さをバイト単位で指定します。 これは、メッセージの本文がチャンクエンコーディングを使用していることを示すために使用できます。 これは、そのメッセージの本文にXNUMXつ以上のデータが含まれていることを意味します。 一部のセキュリティ管理者は、チャンク暗号化がHTTPリクエストで使用できることに気づいておらず、これは問題です。

わからない場合は、HTTPはHTTPメッセージの長さを決定するためのXNUMXつの異なる方法を提供します。 また、XNUMXつのメッセージで両方のメソッドを同時に使用することも可能であり、その場合、それらは互いに競合することに注意してください。 HTTPプロトコルは、Content-LengthヘッダーとTransfer-Encodingヘッダーの両方が存在する場合、Content-Lengthヘッダーを使用しないように指示することで、この問題を解決しようとします。 この式は、アクティブなサーバーがXNUMXつしかない場合はあいまいさを回避するのに十分かもしれませんが、XNUMXつ以上のサーバーがチェーンされている場合はそうではありません。

したがって、フロントエンドサーバーとバックエンドサーバーが、難読化されている可能性のあるTransfer-Encodingタイプのヘッダーに関して異なる動作をする場合、連続するリクエスト間の制限について意見が一致しない可能性があります。 これにより、脆弱性やHTTPリクエストスマグリング攻撃が発生する可能性があります。

この危険な攻撃を防ぐ方法

HTTPリクエストスマグリング攻撃では、Content-LengthヘッダーとTransfer-Encodingヘッダーの両方を同じHTTPリクエストに配置し、フロントエンドサーバーとバックエンドサーバーが異なる方法でリクエストを処理するようにそれらを操作します。

先に述べたKleinは、プロキシサーバーからの発信HTTPリクエストの正規化を求めており、これらのタイプの攻撃を処理できる堅牢でオープンソースのWebアプリケーションファイアウォールソリューションの必要性を強調しています。 この問題を解決するために、KleinはC ++ベースのプロジェクトを公開しました。これにより、すべての着信HTTPリクエストが完全に有効で、準拠し、明確になります。 この作品はGitHubで公開されており、チェックアウトできます 詳細を見る .

一方、HTTPリクエストスマグリング攻撃を回避するためにできる他のいくつかのことは次のとおりです。

  • バックエンド接続の再利用を無効にして、各バックエンド要求が個別のネットワーク接続を介して送信されるようにします。
  • このプロトコルはリクエスト間の境界のあいまいさを回避するため、バックエンド接続にはHTTP / 2を使用します。
  • フロントエンドサーバーとバックエンドサーバーには、まったく同じWebサーバーソフトウェアを使用する必要があります。 これにより、リクエスト間の境界について合意することが保証されます。

ご覧のとおり、HTTPリクエストスマグリング攻撃はその重大度から非常に重要ですが、非常に危険ですが、この攻撃を防止して正しく軽減する方法はいくつかあります。