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

14

Я ищу любое решение для правильного получения запроса 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-7 iis-7.5 bkaid
источник
3
Вы понимаете, что это неполный экранирование URL и неправильный запрос, поэтому 400 обрабатывает его правильно? PercentU и AllowRestricted на самом деле не применимы
Rup
Да, я делаю (и /% - это просто пример URL, но, очевидно, ошибка происходит с каждым недопустимым escape-символом). IIS обрабатывает 400, но я хочу показать пользовательскую страницу 400, как я могу, с другими кодами состояния в IIS, и например, как серверы не-IIS могут за 400.
bkaid
У меня есть несколько мощных ссылок, указывающих на мои сайты, которые по ошибке зашифрованы следующим образом. но я не могу 301 их на правильную страницу, вместо этого это серьезная ошибка. это неприемлемо.
Boomhauer

Ответы:

20

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

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

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

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

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

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

Опасное:

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

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

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

Скотт Форсайт - MVP
источник
Я предпочитаю правильно регистрировать и обрабатывать все ошибки самостоятельно, чтобы отслеживать любую недопустимую странную комбинацию недействительных URL-адресов, которые динамически генерируются на моем сайте - в случае, если один из них не получен надлежащим образом.
bkaid
1
Есть кое-что, что можно сказать о том, как обрабатывать ошибки самостоятельно, но если очевидные ошибки обрабатываются для вас, это хороший бонус. IIS не должен пропускать символы, которые не соответствуют файлу или папке в файловой системе NTFS. Он не знал бы, что делать с путем к папке. Если это не шаблон символов, равный действительному символу, тогда ему нужно будет решить, что делать. В этом случае кажется, что он был выделен для блокировки, а не игнорировать недопустимые символы.
Скотт Форсайт - MVP
@thekaido Как сказал Скотт, нет смысла разбирать неполные URL-адреса. Какую пользовательскую страницу с ошибкой можно создать, поскольку вы не знаете, что пытался сделать пользователь (поскольку запрос не завершен). Обратите внимание, что IE9 даже не позволит вам попасть на сервер с неполным запросом
Джим Б.
Я понимаю последствия всех этих вещей, но Apache и другие веб-серверы допускают это, как и IIS. Неправильно экранированные URL-адреса являются единственными URL-адресами, которые IIS не позволит вам обработать, о которых я знаю. IIS должен разрешать и разрешает использовать другие символы, которые не отображаются в файловой системе NTFS, поскольку мой сайт построен с использованием ASP.NET MVC, где запросы будут перенаправляться на нефайловые ресурсы.
bkaid
На самом деле я исправлен о% в NTFS. Это разрешено, наряду с большинством других персонажей: en.wikipedia.org/wiki/Ntfs . (поиск разрешенных символов в именах файлов).
Скотт Форсайт - MVP
3

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

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

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

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

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

Дейв Уайз
источник
4
Ничего из этого не работает - IIS никогда не передает запрос.
bkaid
Вариант № 1 должен работать независимо от того, что именно, потому что именно так IIS реагирует на ошибку
Дейв Уайз
4
Я только что попробовал вариант 1 и # 2 снова, и ни один из них не работает. IIS обрабатывает этот запрос специально, как упоминает Скотт.
bkaid
3

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

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

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

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

Garrett
источник
2

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

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

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

Гектор Корреа
источник