IIS-Anforderung mit Prozentzeichen in URL (/%) ordnungsgemäß verarbeiten

Ich suche nach einer Lösung, um eine IIS-Anforderung wie /programming//% und http://bing.com/% ordnungsgemäß abzurufen und keine Seite mit ungültigen 400-Anforderungen, sondern eine benutzerdefinierte Fehlerseite anzuzeigen Ähnlich wie bei http://google.com/% und http://facebook.com/% (offensichtlich sind diese Beispiele nicht in IIS enthalten).

Ich glaube, ich habe versucht, alle zutreffenden http.sys-Registrierungseinstellungen (AllowRestrictedChars, PercentUAllowed) per http://support.microsoft.com/kb/820129 festzulegen, aber das hat nicht geholfen. Das Festlegen von AllowRestrictedChars und einer benutzerdefinierten 400-Seite enthält feste URLs wie /programming//%12, jedoch nicht /%.

Dies ist direkt in der IIS-Kernel-Ebene gesperrt. Als Test habe ich jedes Modul in IIS herausgezogen, sodass es nicht einmal einen statischen Page-Handler hatte und trotzdem die 400-Fehlermeldung angezeigt wurde.

Ich glaube nicht, dass es mit IIS möglich ist, das zu umgehen. Die von Ihnen erwähnten Registrierungseinstellungen gelten für andere Arten von eingeschränkten Zeichen. Ich habe keinen Hebel gesehen, um diese Funktionalität zu ändern.

Was ist Ihr Ziel, das zu vermeiden? Es öffnet Ihre Angriffsfläche weiter und ich kann mir nicht vorstellen, dass ein legitimer Besucher durch das Blockieren unvollständiger URL-Escape-Sequenzen verloren geht.

Update2: Hier sind drei großartige Links dazu. Sowohl Nazim Lala als auch Wade Hilmo vom IIS-Team haben darüber wegen der Diskussion um Ihre Frage gebloggt. Auch Scott Hanselman hat einen tollen Beitrag zum Querystring-Teil in .NET:

• Verwendung von Sonderzeichen in IIS - Nazim Lala
• Wie IIS Zeichen in URLs blockiert - Wade Hilmo
• Experimente in Wackiness - Scott Hanselman

Update: Ich habe mich bei einem Mitglied des IIS-Teams erkundigt, um eine verbindliche Antwort zu erhalten. Er erwähnte, dass% gemäß RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ) als unsicher gilt .

Hier ist der relevante Text:

Unsicher:

Zeichen können aus mehreren Gründen unsicher sein. Das Leerzeichen ist unsicher, da signifikante Leerzeichen verschwinden und unwichtige Leerzeichen eingefügt werden können, wenn URLs transkribiert oder gesetzt oder Textverarbeitungsprogrammen unterzogen werden. Die Zeichen "<" und ">" sind unsicher, da sie als Begrenzer für URLs im Freitext verwendet werden. Das Anführungszeichen ("" ") wird in einigen Systemen zum Abgrenzen von URLs verwendet. Das Zeichen" # "ist unsicher und sollte immer codiert werden, da es im World Wide Web und in anderen Systemen zum Abgrenzen einer URL von einem Fragment / Anker verwendet wird möglicherweise folgende Kennung: Das Zeichen "%" ist unsicher, da es für die Kodierung anderer Zeichen verwendet wird. Andere Zeichen sind unsicher, da Gateways und andere Transport-Agents diese Zeichen manchmal ändern. Diese Zeichen sind "{", "}", "|", "\", "^", "~", "[", "]" und "` ".

Alle unsicheren Zeichen müssen immer in einer URL codiert sein. Beispielsweise muss das Zeichen "#" in URLs codiert werden, auch in Systemen, die normalerweise keine Fragment- oder Anker-IDs verarbeiten. Wenn die URL in ein anderes System kopiert wird, das sie verwendet, ist es nicht erforderlich, die zu ändern URL-Codierung.

Daher blockiert IIS dies proaktiv auf der Kernebene, einer proaktiven Sicherheitsmaßnahme zur Minimierung der Angriffsfläche.

Ich kann mir 3 Möglichkeiten vorstellen

1. Ändern Sie IIS so, dass es auf eine benutzerdefinierte Seite für 400 Fehler verweist, als dies normalerweise der Fall ist

2. Wenn dies nur für eine bestimmte Website in IIS gilt, können Sie in der Datei web.config Folgendes tun:

   <customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
   <error statusCode = "400" redirect = "myCustom400Error.aspx" />
   </ customErrors>

3. Schreiben Sie ein httpModule, das die eingehenden URLs überprüft und verarbeitet

Das klingt nur so, als würde man die URL überprüfen, bevor der IIS-Kernel dies kann.

Sie müssen Ihre dynamisch generierten Links über ein Skript senden, um sie zu überprüfen, bevor Sie Ihren Endbenutzer an diese URL weiterleiten ...

Abgesehen davon wissen Sie, dass dies die einzige Situation ist, in der IIS nicht wie gewünscht damit umgeht. Wenn Sie also eine nicht bearbeitete Anfrage haben, wissen Sie durch den Prozess der Beseitigung, was sie verursacht hat.

Vielleicht hilft das Überprüfen des Referrers auf einer benutzerdefinierten 400-Seite, die Quelle des Datenverkehrs einzugrenzen?

Dieser Beitrag im IIS-Forum zeigt an, dass HTTP 400 (Bad Request) von http.sys blockiert wird und es nicht zu IIS schafft, das mit den Links übereinstimmt, die @Scott Forsyth - MVP in seiner ursprünglichen Antwort enthielt.

Sie können ein Protokoll dieser Anforderungen unter c: \ Windows \ System32 \ LogFiles \ HTTPERR \ anzeigen.

Ich weiß nicht, ob Sie die Antwortseite konfigurieren können, die für diese Art von Fehler an den Benutzer zurückgesendet wird, aber da selbst Bing unter diesem Problem leidet, vermute ich, dass dies entweder nicht möglich ist oder schreckliche Systemhacks erfordern würde.