フロントエンド、バックエンド システムに対する攻撃により、サードパーティのリクエストに割り込むことが可能になります。

明らかにした コンテンツ配信ネットワーク、ロード バランサー、プロキシを介して実行されるサイトなど、フロントエンド - バックエンド モデルを使用するサイトに対する新たな攻撃の詳細。この攻撃では、特定のリクエストを送信することで、フロントエンドとバックエンドの間の同じスレッドで処理される他のリクエストの内容に侵入することが可能になります。提案された方法は、PayPal サービスのユーザーの認証パラメータを傍受することを可能にする攻撃を組織するために使用されることに成功しました。PayPal サービスは、パッチが適用されていない脆弱性の存在を知らせるプログラムの一環として研究者に約 40 万ドルを支払いました。この攻撃は、Akamai コンテンツ配信ネットワークを使用しているサイトにも適用されます。

問題の核心は、フロントエンドとバックエンドが HTTP プロトコルに対して異なるレベルのサポートを提供していることが多いのですが、同時に異なるユーザーからのリクエストを共通のチャネルにカプセル化していることです。フロントエンドの受信リクエストとバックエンドの処理リクエストを接続するために、存続期間の長い TCP 接続が確立され、これを通じてユーザーのリクエストが送信され、HTTP プロトコルによって分離されてチェーンに沿って次々に送信されます。リクエストを分離するには、ヘッダー「Content-Length」（リクエスト内のデータの合計サイズを決定します）と「転送エンコーディング: チャンク化(「{size}\r\n{block}\r\n{size}\r\n{block}\r\n0」の形式で異なるサイズのブロックを指定して、データを部分的に転送できます)。

この問題は、フロントエンドが「Content-Length」のみをサポートし、「Transfer-Encoding: chunked」を無視する場合（たとえば、Akamai CDN がこれを行った場合）、またはその逆の場合に発生します。 Transfer-Encoding: chunked が両側でサポートされている場合、HTTP ヘッダー パーサーの実装機能が攻撃に使用される可能性があります (たとえば、フロント エンドが「Transfer-Encoding: xchunked」、「Transfer-Encoding: chunked」などの行を無視する場合) ”、“Transfer-Encoding” :[tab]chunked"、"X: X[\n]Transfer-Encoding: chunked"、"Transfer-Encoding[\n]: chunked" または "Transfer-Encoding : chunked"、およびバックエンドはそれらを正常に処理します)。

この場合、攻撃者は「Content-Length」ヘッダーと「Transfer-Encoding: chunked」ヘッダーの両方を含むリクエストを送信できますが、「Content-Length」のサイズはチャンク チェーンのサイズに対応しません。実際の値より小さいです。フロントエンドが「Content-Length」に従ってリクエストを処理して転送し、バックエンドが「Transfer-Encoding: chunked」に基づいてブロックが完了するのを待機する場合、「Transfer-Encoding: chunked」に基づいてデータの終わりはより早く決定され、攻撃者はリクエストの残りの末尾、つまり次のリクエストの先頭に来ることになります。攻撃者は、次に送信される他人のリクエストの先頭に任意のデータを添付することができます。

使用しているフロントエンドとバックエンドの組み合わせの問題を特定するには、フロントエンド経由で次のようなリクエストを送信できます。

POST /HTTP/1.1について
ホスト：example.com
転送エンコーディング: チャンク化
のContent-Length：4

1
Z
Q

バックエンドがリクエストをすぐに処理せず、チャンク化されたデータの最後のゼロ境界ブロックの到着を待つ場合、問題が発生します。より完全なチェックのために 準備 フロントエンドから「Transfer-Encoding: chunked」ヘッダーを非表示にするための可能な方法もテストする特別なユーティリティ。

実際の攻撃の実行は、攻撃されるサイトの機能によって異なります。たとえば、Trello Web アプリケーションを攻撃する場合、リクエストの先頭を置き換えることができます (「PUT /1/members/1234... x=x&csrf」のようなデータに置き換えます)。 =1234&username=testzzz&bio=cake”) を指定し、サードパーティ ユーザーの元のリクエストとその中で指定された認証 Cookie を含むメッセージを送信します。 saas-app.com に対する攻撃の場合、リクエスト パラメーターの XNUMX つを JavaScript コードに置き換えることで、レスポンス内の JavaScript コードを置き換えることができることが判明しました。 redhat.com への攻撃では、内部ハンドラーを使用して攻撃者の Web サイトにリダイレクトしました (「POST /search?dest=../assets/idx?redir=//」という形式のリクエスト)[メール保護]/HTTP/1.1")。

コンテンツ配信ネットワークの方式を利用することで、「Host:」ヘッダーを置き換えるだけで、要求されたサイトを簡単に置き換えることが可能になりました。この攻撃は、コンテンツ キャッシュ システムのコンテンツを汚染し、キャッシュされた機密データを抽出するためにも使用される可能性があります。この手法の頂点は PayPal に対する攻撃の組織化であり、これにより認証中にユーザーが送信したパスワードの傍受が可能になりました (iframe リクエストは、paypal.com/us/gifts ページのコンテキストで JavaScript を実行するように変更されていました)どの CSP (コンテンツ セキュリティ ポリシー) が適用されなかったのか)。

興味深いことに、2005 年には 提案 本質的に同様のリクエスト スプーフィング手法で、キャッシュ プロキシ (Tomcat、squid、mod_proxy) でデータをスプーフィングしたり、1 つの HTTP セッション内で複数の「GET」または「POST」リクエストを指定することでファイアウォールのブロックをバイパスしたりできます。

出所： オープンネット.ru