Ist EnableHeaderChecking = true genug Header-Injection-Angriffe zu verhindern?

Question

Ist es ausreichend zu haben [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking] ( http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking (VS.85) ASPX-) Satz true (default) vollständig Header-Injection-Angriffe wie Response-Splitting usw. zu verhindern.?

Ich frage, weil ein weißes Feld Penetration Test-Tool (stärken) ausnutzbar Header-Injection Probleme mit HttpResponse.Redirect und Cookies berichtet, aber ich habe keinen Weg, um erfolgreich zu führen einen Angriff gefunden. ( Bearbeiten : .. und wir haben EnableHeaderChecking eingeschaltet ..)

Answer 1

Ich habe seit einiger Zeit auf diesem nun auf der Suche und den Schluss ziehen, dass Einstellung EnableHeaderChecking true ist in der Tat gut genug, um hTTP-Header-Injection-Angriffe zu verhindern.

Mit Blick auf 'reflektiert' ASP.NET-Code, fand ich, dass:

1. Es gibt nur eine Möglichkeit, benutzerdefinierte HTTP-Header eine HTTP-Antwort hinzuzufügen, nämlich die HttpResponse.AppendHeader Methode
2. HttpResponse.AppendHeader entweder
   • erzeugt Instanzen von HttpResponseHeader (intern)
   • oder ruft HttpResponseHeader.MaybeEncodeHeader (für IIS7WorkerRequests)
   • oder ordnet seine jeweiligen Eigenschaften (für bekannte Header wie RedirectLocation oder Content )
3. HttpResponseHeader Instanzen erstellt, bevor bekannt Header wie RedirectLocation oder Content gesendet werden (HttpResponse.GenerateResponseHeaders )
4. Der HttpResponseHeader Konstruktor die EnableHeaderChecking aus:

   <httpRuntime enableHeaderChecking="false"/>

   Fortify nimmt einfach nicht Konfiguration berücksichtigt (Einstellung EnableHeaderChecking keine Wirkung explizit hatte) und damit immer Berichte dieser Art von Fragen.

Answer 2

AFAIK es ist genug, und es sollte standardmäßig eingeschaltet werden.

Ich denke, Fortify ist nur über die Verteidigung in der Tiefe zu denken, als ob Sie die Konfiguration im Einsatz usw. ändern

Ich nehme an, Sie nicht unbedingt in Ihrer Konfiguration auf gesetzt haben, wenn Sie vielleicht haben Fortify ist nicht so klug herausfinden, dass unsere.

Der beste Weg, um es zu bestätigen ausnutzt:)

• Nehmen Sie einfach eine Kopie von Fiedler
• Intercept der Anfrage
• Versuchen Sie neue Zeile zu injizieren
• Prüfen Sie, ob die neue Linie haben Sie gerade in der HTTP-Antwort injiziert ist oder nicht.

Answer 3

EnableHeaderChecking ist nur für nicht vertrauenswürdige Daten. Wenn Sie Daten vorbei direkt aus einem Cookie in einen Redirect, vielleicht die resultierenden Header werden als vertrauenswürdige und \ r \ n-Werte werden nicht entgangen.

Answer 4

Josef, HttpResponse.AppendHeader () ist nicht der einzige Ort, an dem nicht vertrauenswürdige Daten, die die HTTP-Response-Header eingeben.

Jede Daten aus dem Angreifer, die neuen Header in Cookies oder HTTP-Redirects endet schreiben kann, wenn die Daten einen Wagenrücklauf (oder irgendetwas, das als Wagenrücklauf interpretiert wird) enthalten.

In der Regel ist es eine viel bessere Nutzung Ihrer Zeit, um Ihre Daten zu überprüfen, als herumzusitzen und versuchen, Exploits zu erarbeiten. Die Chancen stehen gut, der Hacker als Sie dies besser sein werden oder ich bin.