Правильно обрабатывать запрос IIS со знаком процента в URL (/%)

Я ищу любое решение для правильного получения запроса IIS, например /programming//% и http://bing.com/%, чтобы не отображать страницу 400 Bad Request, но отображать пользовательскую страницу ошибки аналогично тому, как это делают http://google.com/% и http://facebook.com/% (очевидно, этих примеров нет в IIS).

Я полагаю, что попытался установить все применимые параметры реестра http.sys (AllowRestrictedChars, PercentUAllowed) в соответствии с http://support.microsoft.com/kb/820129, но это не помогло. Настройка AllowRestrictedChars и пользовательской страницы 400 имеет фиксированные URL-адреса, такие как /programming//%12, но не /%.

Это заблокировано прямо на уровне ядра IIS. В качестве теста я вытащил каждый модуль в IIS, чтобы у него даже не было статического обработчика страниц, и он по-прежнему отображал сообщение об ошибке 400.

Я не верю, что с IIS возможно обойти это. Параметры реестра, которые вы упомянули, предназначены для других типов запрещенных символов. Я не видел рычаг, чтобы изменить эту функциональность.

Какова ваша цель избежать этого? Это расширяет поверхность вашей атаки, и я не могу представить, чтобы законный посетитель был потерян в результате блокировки неполных escape-последовательностей URL.

Обновление 2: Вот три отличные ссылки на это. И Назим Лала, и Уэйд Хилмо из команды IIS обсуждали этот вопрос в блоге. Также у Скотта Хансельмана есть отличная статья по части строки запросов в .NET:

• Использование специальных символов в IIS - Назим Лала
• Как IIS блокирует символы в URL - Wade Hilmo
• Эксперименты в дураках - Скотт Хансельман

Обновление: я проверил с членом команды IIS, чтобы получить авторитетный ответ. Он упомянул, что% считается небезопасным символом согласно RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Вот соответствующий текст:

Опасное:

Персонажи могут быть небезопасными по ряду причин. Символ пробела небезопасен, потому что значительные пробелы могут исчезнуть, а незначительные пробелы могут быть введены, когда URL-адреса транскрибируются, набираются или подвергаются обработке программ обработки текста. Символы «<» и «>» небезопасны, поскольку они используются в качестве разделителей вокруг URL-адресов в свободном тексте; знак кавычки ("" ") используется для разграничения URL-адресов в некоторых системах. Символ" # "небезопасен и всегда должен кодироваться, поскольку он используется в World Wide Web и в других системах для разграничения URL-адреса из фрагмента / якоря идентификатор, который может следовать за ним. Символ "%" небезопасен, потому что он используется для кодирования других символов. Другие символы небезопасны, поскольку известно, что шлюзы и другие транспортные агенты иногда изменяют такие символы. Это символы "{", "}", "|", "\", "^", "~", "[", "]" и "` ".

Все небезопасные символы всегда должны быть закодированы в URL. Например, символ «#» должен быть закодирован в URL-адресах даже в системах, которые обычно не имеют дело с идентификаторами фрагментов или якорей, поэтому, если URL-адрес копируется в другую систему, которая их использует, нет необходимости изменять Кодировка URL.

Таким образом, IIS активно блокирует это на уровне ядра, упреждающую меру безопасности, чтобы минимизировать их поверхность атаки.

Я могу придумать 3 возможных способа

1. Измените IIS, чтобы указать на пользовательскую страницу на 400 ошибок, чем обычно

2. Если это уникально для определенного веб-сайта в IIS, вы можете сделать что-то вроде этого в файле web.config:

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

3. Напишите httpModule, который проверяет входящие URL и обрабатывает их

Единственный способ обойти это звучит как проверка URL до того, как ядро ​​IIS сможет.

Вам нужно будет отправить динамически сгенерированные ссылки через скрипт, чтобы проверить их, прежде чем перенаправлять конечного пользователя на этот URL ...

За исключением этого, вы знаете, что это единственная ситуация, когда IIS не справится с этим так, как вы хотите. Итак, в процессе устранения, если у вас есть необработанный запрос, вы знаете, что его вызвало.

Возможно, проверка реферера на пользовательской странице 400 поможет сузить источник трафика?

Этот пост на форуме IIS указывает, что HTTP 400 (неверный запрос) заблокирован http.sys, и он не попадает в IIS, который соответствует ссылкам, которые @Scott Forsyth - MVP включил в его первоначальный ответ.

Вы можете просмотреть журнал этих запросов в папке c: \ Windows \ System32 \ LogFiles \ HTTPERR \

Я не знаю, можете ли вы настроить страницу ответа, которая отправляется обратно пользователю для такого рода ошибок, но, поскольку даже Bing страдает от этой проблемы, я подозреваю, что это либо невозможно, либо потребует некоторых ужасных системных хаков.