Понимание нормализации пути в IIS - PullRequest
Новая
       12

Понимание нормализации пути в IIS

4 голосов
/ 13 мая 2019

Я бы хотел отключить обратный путь в каталогах, например example.com/page/../other-page (даже для реальных страниц) на моем веб-сайте IIS.Я пробовал фильтрацию запросов и перезапись URL с пользовательским ответом.

Документация Microsoft по части denyUrlSequences фильтрации запросов фактически использует .. в качестве примера :

В следующем примере файла Web.config будет запрещен доступ к трем последовательностям URL.Первая последовательность предотвращает обход каталога, […] 

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

… но это не работает;example.com/page/../other-page уже стал example.com/other-page еще до того, как запустится правило запрета.Вы можете доказать это, установив правило Запрета для page/sub и посетив example.com/page/./sub-page.Нормализованный путь заблокирован правилом, но он не соответствовал бы в исходном состоянии.

Я проверил это на IIS v7.5 и v10, и я полагаю, что он существует в каждой промежуточной версии,тоже.

  1. Что делает нормализация?(Вероятно, эта библиотека ?)
  2. Когда это происходит в жизненном цикле запроса?
  3. Как успешно заблокировать следующие последовательности, не открывая дыру в безопасности?.., ./ и //

Поиски в Интернете хотят только рассказать мне об уязвимости около 2000 в старой версии IIS или о том, как включить маршруты MVC с точками вих.

Примечание отладки: Если вы используете curl для проверки этого поведения, обязательно добавьте параметр --path-as-is, чтобы он нене делайте нормализацию в клиенте.В некоторых браузерах также выполняется нормализация на стороне клиента.
Примечание по использованию: Я номинально пытаюсь завершить работу example.com/clubs-baby-seals/../about-us, чтобы кто-то не принял успешную загрузку ссылки какодобрение жестокого обращения с печатью.

Ответы [ 2 ]

1 голос
/ 24 мая 2019

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

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

0 голосов
/ 31 мая 2019

Хотя я не знаю конкретного ответа на (1) и (2), для (3) оказывается, что исходный путь URI перед нормализацией доступен в серверной переменной UNENCODED_URL.Это позволяет использовать для него правила перезаписи URL: 

<rule name="Block directory traversal attempts" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAny" trackAllCaptures="false">
        <add input="{UNENCODED_URL}" pattern="\.\." />
        <add input="{UNENCODED_URL}" pattern="\./" />
        <add input="{UNENCODED_URL}" pattern="//" />
    </conditions>
    <action type="CustomResponse" statusCode="404"
            statusReason="Not Found" statusDescription="Page not found" />
</rule>
...