Опасно ли включение двойного побега?

Question

У меня есть приложение ASP.NET MVC с маршрутом, который позволяет искать вещи через / search / .

Когда я задаю «search / abc», он работает хорошо, но когда я задаю «/ search / a + b + c» (правильно закодированный URL), IIS7 отклоняет запрос с ошибкой HTTP 404.11 ( Фильтрация запросов Модуль настроен на отклонение запроса, который содержит двойную escape-последовательность ). Прежде всего, почему он это делает? Кажется, что только выдает ошибку, если она является частью URL, но не как часть строки запроса (/ forward? Q = a + b + c работает нормально).

Теперь я могу включить двойные запросы на экранирование в разделе безопасности моего web.config, но я не решаюсь это сделать, так как не понимаю последствий, а также почему сервер отклоняет запрос "a + b + c "как часть URL, но принимать как часть строки запроса.

Может кто-нибудь объяснить и дать совет, что делать?

Answer 1

Редактировать: Добавлен акцент на соответствующие разделы.

В основном: IIS чрезмерно параноидален. Вы можете безопасно отключить эту проверку, если вы ничего не делаете особенно неразумно с декодированными URI данными (например, генерируете локальные URI файловой системы с помощью конкатенации строк).

Чтобы отключить проверку, сделайте следующее (из здесь ): (см. Мой комментарий ниже, что влечет за собой двойное экранирование).

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true"/>
    </security>
</system.webServer>

Если символ плюса является допустимым символом во входных данных поиска, вам понадобится , чтобы включить «allowDoubleEscaping», чтобы IIS мог обрабатывать такой ввод из пути URI.

Наконец, очень простой, но ограниченный обходной путь - просто избежать «+» и использовать вместо него «% 20». В любом случае, использование символа '+' для кодирования пробела является , а не допустимой кодировкой URL , но специфично для ограниченного набора протоколов и, вероятно, широко поддерживается по причинам обратной совместимости. Если только для целей канонизации, вам все равно лучше кодировать пробелы как «% 20»; и это прекрасно обходит проблему IIS7 (которая все еще может возникать для других последовательностей, таких как% 25ab.)

Answer 2

Я просто хотел бы добавить некоторую информацию к ответу Эамона Нербонна , касающемуся части " что делать " вашего вопрос (не объясняющий почему).
Вы также можете легко изменить настройки конкретного приложения с помощью

1. открытие консоли с правами администратора (Пуск - cmd - щелчок правой кнопкой мыши, Запуск от имени администратора)

2. набрав следующее (взято отсюда: http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx):

   %windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true
   

   (например, вы можете заменить YOURSITENAME на Default Web Site для применения этого правила к веб-сайту по умолчанию)

3. Ввод, готов.

Пример:

1. во-первых, у меня была такая же проблема:
2. Введите текст, указанный выше:
3. Теперь все работает как положено:

Answer 3

Задумывались ли вы о поисковом URL, например, "/ search / a / b / c"?

Вам нужно настроить маршрут, например

search/{*path}

А затем извлеките значения поиска из строки пути в действии.

HTHS
Charles

Answer 4

Я столкнулся с этим в IIS 7.5, выполняя Server.TransferRequest () в приложении.

Кодирование имени файла вызвало проблему двойного выхода, но если я не закодировал его, я столкнулся бы с «потенциально опасным Request.Path» .

Помещение любого протокола, даже пустого, в URL-адрес, который я передаю Server.TranferRequest (), устранил проблему.

Не работает:

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

Работает:

context.Server.TransferRequest("://folder/bar%20bar.jpg");