Назад | Перейти на главную страницу

IIS 7 - Включение запрета последовательностей URL-адресов с обратной косой чертой

Я пытался ограничить обратную косую черту \ в URL-адресах с помощью инструмента фильтрации запросов в IIS 7, используя:

  <configuration>
   <system.webServer>
      <security>
         <requestFiltering>
            <denyUrlSequences>
               <add sequence="\" />
            </denyUrlSequences>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>

Однако правило обратной косой черты полностью игнорируется? Фильтрация запросов определенно работает, как я пробовал со строками вместо обратной косой черты, например. contact-us как правило запрета правильно отправляет вас на страницу 404. Но почему он игнорирует обратную косую черту? Здесь чего-то не хватает?

Спасибо за помощь

Недавно я рассмотрел аналогичную проблему и обнаружил, что обратная косая черта заменяется прямой косой чертой в HTTP.sys до того, как запросы были переданы в IIS. Таким образом, у модуля фильтрации запросов никогда не будет возможности заблокировать запрос, потому что он не увидит обратную косую черту.

Более подробно я отправил следующий запрос

$ wget "http://www.example.com/awesome-category\ awesome-products / "
--2012-08-22 12:51:31 - http://www.example.com/awesome-category%5Cawesome-products/
Разрешение www.example.com ... 192.168.1.77
Подключение к www.example.com | 192.168.1.77 |: 80 ... подключено.
HTTP-запрос отправлен, ожидает ответа ... 200 ОК
Длина: 56398 (55 КБ) [text / html]
Сохранение в: `index.html '

2012-08-22 12:51:38 (6,60 МБ / с) - `index.html '

И в Wireshark появилось следующее:

4 0.001242000 192.168.200.42 192.168.100.177 HTTP 246 GET / awesome-category% 5Cawesome-products / HTTP / 1.0

Я также настроил Трассировка событий HTTP.sys чтобы увидеть, что происходило до того, как HTTP.sys передал запрос IIS и .NET.

Он показал URL без обратной косой черты:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-HttpService" Guid="{dd5ef90a-6398-47a4-ad34-4dcecdef795f}" />
        <EventID>2</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>1</Task>
        <Opcode>12</Opcode>
        <Keywords>0x8000000000000002</Keywords>
        <TimeCreated SystemTime="2012-08-22T11:51:29.179726800Z" />
        <Correlation ActivityID="{80000663-0000-5d00-b63f-84710c7967bb}" />
        <Execution ProcessID="4" ThreadID="1912" ProcessorID="0" KernelTime="8820" UserTime="0" />
        <Channel>Microsoft-Windows-HttpService/Trace</Channel>
        <Computer />
    </System>
    <EventData>
        <Data Name="RequestObj">0xFFFFFA801C33B530</Data>
        <Data Name="HttpVerb">       4</Data>
        <Data Name="Url">http://www.example.com.com:80/awesome-category/awesome-products</Data>
    </EventData>
    <RenderingInfo Culture="en-GB">
        <Level>Information </Level>
        <Opcode>Parse </Opcode>
        <Keywords>
            <Keyword>Flagged on all HTTP events dealing with request processing </Keyword>
        </Keywords>
        <Task>HTTP Request Trace Task </Task>
        <Message>Parsed request (request pointer 0xFFFFFA801C33B530, method 4) with URI http://www.example.com.com:80/awesome-category/awesome-products. </Message>
        <Channel>HTTP Service Channel </Channel>
        <Provider>Microsoft-Windows-HttpService </Provider>
    </RenderingInfo>
</Event>

Насколько я могу судить, HTTP.sys очищает обратную косую черту в URL-адресе, заменяя ее прямой косой чертой. Это поведение было задокументировано для IIS 6. Вот:

Нормализация отличается, когда используется обход каталога. Например, получен такой запрос:

http://www.example.com/RootTest/SubDir1\ SubDir2 /../../ SubDir5 / SubDir6

Http.sys нормализует этот URL как следующий URL:

http://www.example.com/RootTest/SubDir5/SubDir6

Примечание: обратная косая черта заменяется прямой косой чертой. ".

Это также упоминалось совсем недавно Вот:

Любые символы «\» (обратная косая черта) в URI, отправляемом в IIS / WAS, автоматически преобразуются в «/» (косая черта). Если добавлен относительный адрес, содержащий "\", и вы отправляете IIS URI, который использует относительный адрес, обратная косая черта преобразуется в прямую косую черту, и IIS не может сопоставить ее с относительным адресом. IIS отправляет информацию трассировки, которая указывает на то, что совпадений не найдено.

У меня такое же поведение на другом сервере, поэтому я подозреваю, что это невозможно сделать с помощью фильтрации запросов, в отличие от некоторых документов на iis.net. Было бы здорово получить более четкое подтверждение от кого-нибудь из MS, но я ничего не нашел.

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