web-dev-qa-db-ja.com

この応答分割攻撃が機能しないのはなぜですか？

私はOWASPの「WebGoat」（バージョン5.4）の脆弱なWebアプリケーションを使用していますが、HTTP応答分割に関する最初のレッスンの1つに行き詰まっています。

私はすべてのヒントと解決策を調べました（そして、interwebsに点在するすべてのチュートリアルでさえ調べました）が、それでも機能させることができません。

Webサーバーの応答も完全に変更しました。

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=en
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Graeme</html>
Content-Type: text/html;charset=ISO-8859-1
Content-length: 0
Date: Sun, 28 Jul 2013 20:26:13 GMT

私はこれが私のブラウザに "Grezzo"を表示させることになっているとかなり確信していますが、代わりに2番目の応答ではなく最初の応答に従います。最初の "Content-Length：0"行も削除してみましたが、違いはありません。

何が起きてる？何か不足していますか？おそらく、最近のWebブラウザーは常に最初の応答に従いますか？

web-applicationhttphttp-proxyresponse-splittingwebgoat
5
Grezzo

最も頻繁に省略されるHTTP応答分割（HRS）の基本的な部分はプロキシです。

HRSは、Webサーバーとブラウザー、またはブラウザーとWebサーバー間の攻撃ではありません。
攻撃は、準準拠のHTTPデバイス、つまりWebサーバーとWebプロキシの特異性に対するものです。
具体的には、攻撃は、Webサーバーが1つの応答セット（1つの応答）を認識し、プロキシが別のセット（2つの応答）を認識し、proxy splitsという事実を利用します。 1つは被害者への要求、もう1つは攻撃者（またはエーテル）への要求です。

したがって、この攻撃をテストするには、次の設定が必要です。

  1. ウェブサーバー
  2. 代理
  3. 被害者のブラウザ
  4. 攻撃者クライアント（またはブラウザ）

プロキシの部分を見逃したと思います...

10
AviD

私はハッカーマンではありませんが）、攻撃はサーバーに依存していると思います。したがって、サーバーがリクエストを正しく処理しない（またはレスポンスを正しく処理しない）場合、攻撃は成功します。

Broswerは常に最初の応答を処理します（古いブラウザーも最初の応答を処理します）。

しかし、この攻撃は、サーバーがヘッダー（例：Cookie）の1つに変数を配置したときに常に機能します。サーバーがリクエストを処理するとき、それは変数をTextareaからcookieに入れます（絶対に行わないでください）。したがって、クライアントはtextareaに次の文字列を書き込むことができます。

some data to cookies
Content-Type: text/html
Content-Length: 16

<H1>Hacked</H1>

したがって、サーバーがこの文字列をcookieに書き込むと、サーバーからの応答は次のようになります。

Connection:keep-alive
Content-Type:this server content-type (for example: application/json)
Set-Cookie:qqq="some data to cookies
Content-Length:16  -  your length
Content-Type:text/html - your content type 

<H1>Hacked</H1>

これはサーバーのバグではなく、Webサイトを作成するプログラマーのバグです。

0
Logioniz

必ずキャリッジリターンを使用してください。 PHP Charset Encoderは%0Aでのみエンコードしますが、応答で改行を取得するには%0D%0Aである必要があります。これが行われた場合のみ、応答はHTTP 200 OK（または必要なもの）。

0
Thomas