Erlaube doppelten URL-codierten Anforderungspfaden, gültig zu sein

OK, nach vielen Recherchen im Internet und vielen Experimenten denke ich, dass ich endlich verstehe, was vor sich geht. Mein Hauptproblem war ein extremer Bestätigungsfehler. Alles, was ich las, sagte, was ich hören wollte und nicht, was es eigentlich gesagt hatte. Ich werde die wichtigsten Punkte zusammenfassen, die ich verstehen musste, um meine Frage zu beantworten.

1. Zuerst musste ich verstehen, dass IIS und ASP.Net zwei verschiedene Anwendungen sind. Was IIS auf den Punkt bringt, ist, eine Anforderung zu erhalten, diese Anforderung an eine Anwendung weiterzuleiten, die sie verarbeitet, die Ausgabe von der Verarbeitungsanwendung zu erhalten und dann die Ausgabe von der Anwendung zurück an den Anforderer zu senden. Was ASP.Net tut, empfängt die Anforderung von IIS, verarbeitet sie und gibt die Antwort dann an IIS zurück. Das ist eine große Verallgemeinerung des gesamten Prozesses, aber für meine Zwecke ist es gut genug. 1

2. Eingehende ASP.Net-Anfragen müssen zwei Gatekeeper passieren. Das RequestFiltering-Modul von IIS7 (konfiguriert in system.webserver / requestFiltering 2 ) und dann der ASP. Net HttpRuntime Anfrage Filter (konfiguriert in system.web / httpRuntime 3 ).

3. Das IIS RequestFiltering-Modul ist das einzige Modul, das eingehende Anforderungen normalisiert und nur einmal die Normalisierung anwendet. Wieder wiederhole ich es nur ein Mal. Auch wenn <requestFiltering allowDoubleEscaping="true" /> gilt, wird die Normalisierung nur einmal angewendet. Das bedeutet, dass "% 2520" auf "% 20" normalisiert wird. An dieser Stelle, wenn allowDoubleEscaping falsch ist, wird IIS die Anfrage nicht durchlassen, da "% 20" noch normalisiert werden kann. Wenn jedoch allowDoubleEscaping auf True gesetzt ist, wird IIS7 die Anfrage '% 20' an den nächsten Gatekeeper, ASP.Net, übergeben. Dies war die Ursache für den ersten Fehler.

4. Im Asp.net-Filter werden die requestPathInvalidCharacters überprüft. Nun ist unser '% 20' ungültig, weil '%' standardmäßig ein Teil von requestPathInvalidCharacters ist. Wenn wir das '%' aus dieser Liste entfernen, werden wir es durch den zweiten Gatekeeper schaffen und ASP.Net wird versuchen, unsere Anfrage zu bearbeiten. Dies war die Ursache für den zweiten Fehler.

5. Jetzt versucht ASP.net unseren virtuellen Pfad in einen physischen auf dem Server zu konvertieren. Leider haben wir immer noch eine '% 20' in unserem Pfad statt der '' wollen wir so ASP.Net ist nicht in der Lage, die Ressource zu finden, die wir wollen und wirft eine "Ressource kann nicht gefunden werden Fehler". Der Grund, warum der Pfad für mich richtig aussah, als ich meinen Code einbrach, liegt darin, dass ich die Eigenschaft "Request.Url" überwacht habe. Diese Eigenschaft versucht, hilfreich zu sein, indem sie ihre eigene Normalisierung in ihrer ToString () -Methode anwendet, wodurch unser% 20 wie das "wir wollen, auch wenn es nicht ist" aussieht. Dies war die Ursache für den endgültigen Fehler.

Um dies zu erreichen, könnten wir unser eigenes benutzerdefiniertes Modul schreiben, das die Anfrage nach den ersten beiden Gatekeepern empfängt und vollständig normalisiert, bevor es an ASP.Net übergeben wird. Wenn Sie dies jedoch tun, können alle Zeichen durchkommen, solange sie URL-codiert sind. Zum Beispiel wollen wir normalerweise kein '& lt; oder ein '& gt;' auf unseren Wegen, da diese verwendet werden können, um Tags in unseren Code einzufügen. Wie die Dinge jetzt funktionieren, ist die & lt; und & gt; wird nicht über den ASP.Net-Filter hinauskommen, da sie Teil der requestPathInvalidCharacters sind. Sie können jedoch als% 253C und% 253E codiert werden, wenn wir die ersten beiden Gatter öffnen und dann die Anforderung in unserem eigenen benutzerdefinierten Modul normalisieren, bevor Sie sie an ASP.Net übergeben.

Zusammenfassend lässt sich die vollständige Normalisierung von% 2520 nicht ohne eine große Sicherheitslücke erreichen. Wenn es möglich wäre, dem RequestFiltering-Modul mitzuteilen, dass es jede Anforderung vollständig normalisiert, bevor es diese Anfrage an die ersten beiden Gatekeeper absetzt, wäre es viel sicherer, aber im Moment ist diese Funktionalität nicht verfügbar.

Wenn ich etwas falsch gemacht habe, lass es mich wissen und ich hoffe, das hilft jemandem.

Wenn Sie doppeltes Escaping zulassen möchten, können Sie den Anweisungen unter folgen Ссылка

Es funktionierte für mich auf IIS 7.0 mit keiner anderen erforderlichen Konfiguration. Double-Escaping hat keine Auswirkungen auf den Code der Website, auf der ich es implementiert habe; Ich weiß nicht, welche möglichen Sicherheitsimplikationen es für andere Sites geben könnte.