Я ищу любое решение для правильного получения запроса IIS, например https://stackoverflow.com/% и http://bing.com/% не отображать страницу 400 неверных запросов, но отображать настраиваемую страницу ошибок, аналогичную тому, как http://google.com/% и http://facebook.com/% делать (очевидно, что этих примеров нет в IIS).
Я считаю, что попытался установить все применимые параметры реестра http.sys (AllowRestrictedChars, PercentUAllowed) для http://support.microsoft.com/kb/820129 но это не помогло. Настройка AllowRestrictedChars и настраиваемая страница 400 имеет фиксированные URL-адреса, например https://stackoverflow.com/%12 но нет /%.
Это заблокировано прямо на уровне ядра IIS. В качестве теста я вытащил каждый модуль в IIS, так что у него даже не было статического обработчика страницы, и он по-прежнему отображал сообщение об ошибке 400.
Я не верю, что с помощью IIS можно обойти это. Указанные вами параметры реестра предназначены для других типов запрещенных символов. Я не видел рычага, чтобы изменить эту функциональность.
Какая ваша цель избежать этого? Это открывает более широкую поверхность для атаки, и я не могу себе представить, чтобы законный посетитель был потерян в результате блокировки неполных escape-последовательностей URL.
Обновление2: Вот три отличные ссылки по этому поводу. И Назим Лала, и Уэйд Хилмо из группы IIS писали об этом в блоге из-за обсуждения вашего вопроса. Также у Скотта Хансельмана есть отличный пост о части запроса в .NET:
Обновить: Я посоветовался с одним из членов команды IIS, чтобы получить авторитетный ответ. Он упомянул, что% считается небезопасным символом согласно RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt).
Вот соответствующий текст:
Небезопасно:
Персонажи могут быть небезопасными по ряду причин. Символ пробела небезопасен, потому что значительные пробелы могут исчезнуть, а незначительные пробелы могут появиться, когда URL-адреса транскрибируются или набираются, или подвергаются обработке программ обработки текстов. Символы «<» и «>» небезопасны, потому что они используются в качестве разделителей URL-адресов в свободном тексте; кавычки ("" ") используются для разделения URL-адресов в некоторых системах. Символ" # "небезопасен и всегда должен кодироваться, потому что он используется во всемирной паутине и в других системах для отделения URL-адреса от фрагмента / привязки идентификатор, который может следовать за ним. Символ «%» небезопасен, потому что он используется для кодирования других символов. Другие символы небезопасны, поскольку известно, что шлюзы и другие транспортные агенты иногда изменяют такие символы. Это символы "{", "}", "|", "\", "^", "~", "[", "]" и "` ".
Все небезопасные символы всегда должны кодироваться в URL. Например, символ «#» должен быть закодирован в URL-адресах даже в системах, которые обычно не имеют дело с идентификаторами фрагментов или привязок, так что если URL-адрес копируется в другую систему, которая их использует, не нужно будет изменять Кодировка URL.
Таким образом, IIS упреждающе блокирует это на уровне ядра, что является упреждающей мерой безопасности, чтобы минимизировать поверхность атаки.
Единственный способ обойти это похоже на проверку URL-адреса до того, как это сделает ядро IIS.
Вам нужно будет отправить свои динамически сгенерированные ссылки через скрипт, чтобы проверить их, прежде чем перенаправить вашего конечного пользователя на этот URL ...
Если исключить это, вы знаете, что это единственная ситуация, когда IIS не справится с этим так, как вы хотите. Итак, в процессе исключения, если у вас есть необработанный запрос, вы знаете, что его вызвало.
Возможно, проверка реферера на настраиваемой странице 400 поможет сузить источник трафика?
Я могу придумать 3 возможных способа
Измените IIS, чтобы он указывал на настраиваемую страницу для 400 ошибок, чем обычно
Если это уникально для определенного веб-сайта в IIS, вы можете сделать что-то вроде этого в файле web.config:
<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Напишите httpModule, который проверяет входящие URL-адреса и обрабатывает их.
это Почта на форуме IIS указывает, что HTTP 400 (неверный запрос) заблокирован http.sys и не попадает в IIS, который соответствует ссылкам, которые @Scott Forsyth - MVP включил в свой исходный ответ.
Вы можете увидеть журнал этих запросов в c: \ Windows \ System32 \ LogFiles \ HTTPERR \
Я не знаю, можете ли вы настроить страницу ответа, которая отправляется обратно пользователю для такого рода ошибок, но поскольку даже Bing страдает от этой проблемы, я подозреваю, что это либо невозможно, либо потребует ужасных системных взломов.