URLのパーセント記号（/％）を使用してIIS要求を適切に処理する

/programming//%やhttp://bing.com/%などのIIS要求を適切に取得して、400 Bad Requestページを表示せずにカスタムエラーページを表示するためのあらゆる種類のソリューションを探していますhttp://google.com/%およびhttp://facebook.com/%の動作に似ています（明らかに、これらの例はIISにはありません）。

http://support.microsoft.com/kb/820129ごとに、該当するすべてのhttp.sysレジストリ設定（AllowRestrictedChars、PercentUAllowed）を設定しようとしたが、それは役に立たなかったと思う。AllowRestrictedCharsとカスタム400ページを設定すると、https：//stackoverflow.com/%12などの固定URL がありますが、/％はありません。

これは、IISカーネルレベルでブロックされます。テストとして、静的ページハンドラーさえも持たないようにIISのすべてのモジュールを引き出しましたが、それでも400エラーメッセージが表示されました。

IISでそれを回避できるとは思いません。あなたが言及したレジストリ設定は、他の種類の制限文字用です。その機能を変更するためのレバーを見たことはありません。

あなたの目標はそれを避けることですか？それはあなたの攻撃面をより広く開き、不完全なURLエスケープシーケンスをブロックした結果として正当な訪問者が失われることは想像できません。

Update2： これに関する3つの素晴らしいリンクがあります。IISチームのNazim LalaとWade Hilmoの両方が、あなたの質問に関する議論のためにこれについてブログに書いています。また、Scott Hanselmanは、.NET内のクエリ文字列部分に関する素晴らしい投稿をしています。

• IISでの特殊文字の使用 -Nazim Lala
• IISがURLの文字をブロックする方法 -Wade Hilmo
• ワッキーネスの実験-Scott Hanselman

更新： IISチームのメンバーに確認して、信頼できる回答を得ました。彼は、RFC 1738（http://www.ietf.org/rfc/rfc1738.txt）によると、％は安全でない文字と見なされると述べました。

関連するテキストは次のとおりです。

安全でない：

文字は、いくつかの理由で安全でない場合があります。スペース文字は安全ではありません。URLが文字起こしまたはタイプセットされたり、ワープロプログラムの処理が行われたりすると、重要なスペースが消えたり、意味のないスペースが導入される可能性があるためです。文字「<」および「>」は、フリーテキストのURLの区切り文字として使用されるため、安全ではありません。一部のシステムでは、引用符（ "" "）を使用してURLを区切ります。文字"＃ "は安全ではなく、World Wide Webや他のシステムでURLをフラグメント/アンカーから区切るために使用されるため、常にエンコードする必要がありますそれに従うことがあります。識別子 、それが他の文字のエンコードに使われているため、文字「％」は安全ではありません。 ゲートウェイや他のトランスポートエージェントはこのような文字を変更することがあるため、他の文字は安全ではありません。これらの文字は、「{」、「}」、「|」、「\」、「^」、「〜」、「[」、「]」、および「 `」です。

安全でない文字はすべて、常にURL内でエンコードする必要があります。たとえば、通常はフラグメントまたはアンカー識別子を処理しないシステムでも、文字「＃」をURL内でエンコードする必要があります。そのため、URLを使用する別のシステムにURLをコピーしても、変更する必要はありませんURLエンコード。

したがって、IISはこれをコアレベルでプロアクティブにブロックします。これは、攻撃対象を最小限に抑えるプロアクティブなセキュリティ対策です。

私は3つの可能な方法を考えることができます

1. 通常よりも400エラーのカスタムページを指すようにIISを変更します

2. これがIISの特定のWebサイトに固有の場合、web.configで次のようなことができます。

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

3. 着信URLを検査して処理するhttpModuleを作成します

これを回避する唯一の方法は、IISカーネルが実行する前にURLをチェックするようなものです。

エンドユーザーをそのURLに転送する前に、動的に生成されたリンクをスクリプトで送信してチェックする必要があります...

それを除けば、IISが希望どおりに処理できない唯一の状況であることがわかります。したがって、除去のプロセスにより、未処理のリクエストがある場合は、それが原因であることがわかります。

カスタム400ページでリファラーをチェックすると、トラフィックのソースを絞り込むのに役立つでしょうか？

IISフォーラムのこの投稿は、HTTP 400（Bad Request）がhttp.sysによってブロックされ、@ Scott Forsyth-MVPが元の回答に含めたリンクに一致するIISに到達しないことを示しています。

これらのリクエストのログは、c：\ Windows \ System32 \ LogFiles \ HTTPERR \で確認できます。

この種のエラーに対してユーザーに返される応答ページを構成できるかどうかはわかりませんが、Bingでさえこの問題に苦しんでいるので、それは不可能であるか、恐ろしいシステムハックが必要になると思われます。