ASP.NET MVC "Potenziell gefährlicher Request.Path" mit gültiger URL

Question

Auf meiner Produktions-ASP.NET MVC 3-Site bemerkte ich gelegentlich "Ein potentiell gefährlicher Request.Path-Wert wurde vom Client erkannt (%)" . " unbehandelte Ausnahme im Windows-Anwendungsprotokoll.

Während diese unter normalen Site-Nutzung (dh/zufällige Web-Bots) perfekt gültig sein können, scheint eine Anzahl der Anfragen von gültigen, lokalen ISP-Benutzern zu stammen.

in der Anfrage Einzelheiten über die Ausnahme, ist die Anforderungs-URL anders als der Weg anfordern:

Anforderungs-URL: http://www.somesite.com/Images/Image Mit space.jpg

Anfrage Pfad:/Bilder/Imagehttp: // www. somesite.com/Images/Image Mit Space.jpgWithhttp: //www.somesite.com/Images/Image Mit Space.jpgSpace.jpg

Beachten Sie, dass in der "Anforderungspfad", an jedem Ort gibt es eine " Leerzeichen "im Pfad wird durch eine exakte Kopie ersetzt der Anfrage URL!

Innerhalb der Website, sieht die tatsächliche Link wie folgt:

<img src="/Images/Image%20With%20Space.jpg" /> 

Jede Idee, was dies verursachen könnte? Ich habe versucht, die Dokumentation für Request.Path und Request.Url zu betrachten, aber ich kann nicht herausfinden, warum sie anders sein würden. Wenn Sie die Anfrage-URL direkt eingeben, wird die Ressource korrekt angezeigt.

Update: Ich schaffte es eine Spur von einem der Fehlfunktion Anfragen zu erhalten, indem IIS 7.0 Anforderungsfehler Tracing-Funktion:

Referer: Google-Suche

User-Agent: Mozilla/5.0 (iPad, CPU OS 5_1_1 wie Mac OS X) AppleWebKit/534,46 (KHTML, wie Gecko) Version/5.1 mobile/9B206 Safari/7534.48.3

RequestURL: http://www.somesite.com:80/Images/Image%20With%20Space.jpg

Wenn Sie die URL manuell in mein iOS 5.1.1 eingeben, wird das Bild korrekt angezeigt. Wenn Sie in Google Bilder nach dem Bild suchen, wird das Bild korrekt angezeigt. Noch immer keine erfolgreiche Reproduktion.

leicht ange der Spur Ich sehe:

MODULE_SET_RESPONSE_ERROR_STATUS Warnung. Module = "Request", Mitteilung = "BEGIN_REQUEST", Httpstatus = "404", HttpReason = "nicht gefunden", HttpSubStatus = "11",

Nach IIS‘Dokumentation, 404,11 aus dem Request Filtering-Modul ein "Doppelcodierungsfehler" in der URL. Ein wenig experimentierfreudig, wenn ich absichtlich eine doppelt codierte URL wie http://www.somesite.com/Images/Image%2520With%2520Space.jpg erstelle, bekomme ich den genauen Fehler im Ereignisprotokoll, komplett mit fehlerhaftem Anfragepfad.

Der fehlerhafte Anforderungspfad im Ereignisprotokollfehler scheint ein Fehler in ASP.NET 4.0 zu sein.

Es erklärt jedoch nicht, warum ich den Fehler in erster Linie bekomme. Ich habe eine große Anzahl fehlgeschlagener Anfrageprotokolle überprüft - der einzige gemeinsame Faktor ist, dass sie alle AppleWebKit verwenden.Könnte es ein Bug in Safari sein?

Answer 1

Der httpRuntime-Abschnitt der Web.Config kann geändert werden, um die URL-Überprüfung anzupassen. ASP MVC-Projekte werden normalerweise im Validierungsmodus 2.0 ausgeführt und die standardmäßigen ungültigen Zeichen (getrennt durch Kommas) sind unten aufgeführt.

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,&amp;,\" /> 

Wie Sie sehen können, wird das% -Zeichen als ungültig betrachtet. Ein Leerzeichen kann in% 20 codiert werden, wodurch der Validierungsfehler verursacht wird. Sie können einfach das requestPathInvalidCharacters-Attribut zum httpRuntime-Abschnitt in Ihrer Web.Config-Datei hinzufügen und die Werte kopieren, die unten aufgeführt sind, mit Ausnahme des Teils "%".

Scott Hanselman hat einen Blog-Beitrag zu diesem Problem:

http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

Answer 2

ich nicht, dass das Denken helfen kann - angesichts der eingeschränkten User-Agent - das von diesem Browser eine falsche Handhabung der URL darstellen könnte auf IOS 5.1.1. Ich besitze ein solches Gerät nicht persönlich, also kann ich das nicht testen - aber es wäre interessant zu untersuchen, wie es sich mit einer URL verhält, die tatsächlich Leerzeichen enthält.

Ich habe das Gefühl, dass es die in der URL von der Seitenquelle und Doppel-Codierung es sieht, denke, es ist hilfreich. Das Problem dabei ist, dass IIS es zurückdecodieren wird (bevor ASP.net einsetzt) ​​und es aus seinem Wagen rattern lässt, weil es jetzt statt eines Leerzeichens ein Literal sieht.

Ich empfehle persönlich nicht die Sicherheitseinstellungen Ihrer Server zu ändern; aber es wäre die einfachste Lösung, also wage ich zu sagen, dass Sie das tun werden.

Eher, ich denke, wenn Sie diesen "Bug" bestätigen können (ich bin schon unterwegs, finde ein sicheres Versteck von Apples Anwälten), finde ein Format, das für dieses Gerät funktioniert; oder nehmen Sie alle Leerzeichen aus Ihren Ressourcen-URLs. A - ist die beste Alternative.