10

[ System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking (VS.85).aspx)を(デフォルト)に設定してtrue、Httpを完全に防止するだけで十分ですか?応答分割などのヘッダーインジェクション攻撃?

ホワイトボックス侵入テストツール(fortify)がHttpResponse.RedirectCookieに関する悪用可能なhttpヘッダーインジェクションの問題を報告しているので質問していますが、攻撃を正常に実行する方法が見つかりません。(編集:..そしてEnableHeaderCheckingがオンになっています..)

4

4 に答える 4

7

私はこれをしばらく検討しており、EnableHeaderCheckingを に設定trueすることで、実際には HTTP ヘッダー インジェクション攻撃を防ぐのに十分であるという結論を導き出しました。

「反映された」ASP.NETコードを見ると、次のことがわかりました。

  1. カスタム HTTP ヘッダーを HTTP 応答に追加する唯一の方法は、HttpResponse.AppendHeaderメソッドを使用することです。
  2. HttpResponse.AppendHeaderのいずれか
    • HttpResponseHeader(内部)のインスタンスを作成します
    • またはコールHttpResponseHeader.MaybeEncodeHeader(の場合IIS7WorkerRequests
    • またはそれぞれのプロパティを割り当てます ( RedirectLocationContentTypeなどの既知のヘッダーの場合)
  3. HttpResponseHeaderインスタンスは、RedirectLocationContentTypeなどの既知のヘッダーが送信される前に作成されます ( HttpResponse.GenerateResponseHeaders)
  4. コンストラクターはEnableheaderChecking設定をHttpResponseHeaderチェックし、設定されている場合は呼び出しますHttpResponseHeader.MaybeEncodeHeadertrue
  5. HttpResponseHeader.MaybeEncodeHeaderHTTPヘッダーインジェクション攻撃を不可能にする改行文字を正しくエンコードします

これは、私がどのようにテストしたかを大まかに示すためのスニペットです。

// simple http response splitting attack
Response.AddHeader("foo", "bar\n" + 
    // injected http response, bad if user provided
    "HTTP/1.1 200 OK\n" + 
    "Content-Length: 19\n" +
    "Content-Type: text/html\n\n" +
    "<html>danger</html>"
);

上記は、 EnableHeaderCheckingを明示的にオフにした場合にのみ機能します。

<httpRuntime enableHeaderChecking="false"/>

Fortify は単純に構成を考慮しないため ( EnableHeaderChecking を明示的に設定しても効果がありません)、常にこの種の問題を報告します。

于 2009-05-22T15:30:41.610 に答える
0

Josef、HttpResponse.AppendHeader() は、信頼できないデータが HTTP 応答ヘッダーに入る唯一の場所ではありません。

データに改行 (または改行として解釈されるもの) が含まれている場合、最終的に Cookie または HTTP リダイレクトになる攻撃者からのデータは、新しいヘッダーを書き込むことができます。

一般に、じっと座ってエクスプロイトを解決しようとするよりも、データを検証する方が時間を有効に活用できます。おそらく、ハッカーはあなたや私よりも優れているでしょう。

于 2010-07-22T23:06:55.027 に答える