Использование фильтрации запросов

Команда IIS

Введение

UrlScan, средство безопасности, было предоставлено в качестве надстройки для более ранних версий служб IIS, чтобы администраторы могли применять более жесткие политики безопасности на своих веб-серверах. В IIS 7 и более поздних версиях все основные функции URLScan были включены в модуль "Фильтрация запросов", а функция "Скрытые сегменты" добавлена. В этой статье описывается каждая функция фильтрации запросов и приведены примеры применения функций в вашей среде.

Обратите внимание, что IIS также включает модуль для переписывания адресов URL. Существуют различия между этими двумя модулями: фильтрация запросов разработана и оптимизирована для сценариев безопасности, а перезапись URL-адресов может применяться для широкого набора сценариев (сценарии безопасности являются лишь подмножеством этих сценариев). Дополнительные сведения о различиях см. в статьях IIS 7.0 и более поздних версий фильтрации запросов и перезаписи URL-адресов.

Фильтрация двойной кодировки запросов

Эта функция предотвращает атаки, основанные на двухкодированных запросах, и применяется, если злоумышленник отправляет тщательно созданный двойный запрос в IIS. Если включен фильтр запросов с двойной кодировкой, СЛУЖБЫ IIS нормализует URL-адрес дважды; Если первая нормализация отличается от второй, запрос отклоняется, а код ошибки, зарегистрированный в журнале, равен 404.11. Фильтр двухкодированных запросов был параметром VerifyNormalization в UrlScan.

Если вы не хотите, чтобы IIS допускал обработку запросов с двойным кодированием, используйте следующее:

<configuration>
 <system.webServer> 
  <security>
   <requestFiltering
                  allowDoubleEscaping="false">
   </requestFiltering> 
  </security>
 </system.webServer>
</configuration>

Фильтрация больших битовых символов

Эта функция разрешает или отклоняет все запросы к СЛУЖБАм IIS, которые содержат символы, отличные от ASCII, и регистрирует код ошибки 404.12. Эквивалент UrlScan — AllowHighBitCharacters.

Например, предположим, что вы хотите разрешить большие битовые символы для одного приложения, но не для всего сервера. Задайте allowHighBitCharacters="false" в файле ApplicationHost.config; но в корне приложения создайте файл Web.config, который позволяет одному приложению принимать символы, отличные от ASCII. В файле Web.config используйте следующую команду:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering
                  allowHighBitCharacters="true"
            >
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Фильтрация на основе расширений файлов

Эта функция определяет набор разрешенных расширений файлов, обслуживаемых службами IIS. Если IIS отклоняет запрос на основе расширений файлов, код ошибки записывается в журнал 404.7. Параметры AllowExtensions и DenyExtensions — эквиваленты UrlScan.

Например, предположим, что вы хотите разрешить каждый тип файла, кроме ASP-файлов. Задайте опцию allowUnlisted для fileExtensions в значение "true", а затем задайте расширение файла, чтобы явно запретить ASP:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <fileExtensions allowUnlisted="true" >
     <add fileExtension=".asp" allowed="false"/>
    </fileExtensions>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Фильтрация на основе ограничений запросов

Этот фильтр объединяет три функции (которые имеют одинаковые имена в UrlScan):

• maxAllowedContentLength –верхний предел размера содержимого
• maxUrl–верхняя граница длины URL-адреса
• maxQueryString –верхняя граница длины строки запроса

Если IIS отклоняет запрос на основе ограничений запросов, код ошибки регистрируется:

• 413.1, если содержимое слишком длинно.
• 404.14, если URL-адрес слишком велик.
• 404.15, если строка запроса слишком длинна.

Например, для компаний очень распространено приобретение программного обеспечения, к которому у них нет доступа к исходному коду. Со временем они могут находить уязвимости в этом коде. Получение обновлений для затронутого кода часто не так просто. Проблемы часто вызываются url-адресом или строкой запроса, слишком длинной или чрезмерной частью содержимого, отправляемого приложению. После определения безопасной верхней границы можно применить ограничения, используя приведенную ниже конфигурацию, не исправив двоичные файлы приложения:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <requestLimits
       maxAllowedContentLength="30000000"
       maxUrl="260"
       maxQueryString="25" 
                  />
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Фильтрация по глаголам

Эта функция определяет список команд, которые IIS принимают в рамках запроса. В случае, если служба IIS отклоняет запрос на основе этой функции, в журнале регистрируется код ошибки 404.6. Это соответствует параметрам UseAllowVerbs, AllowVerbs и DenyVerbs в UrlScan.

Например, предположим, что вы хотите разрешить только команду GET. Чтобы задать это, необходимо сначала заблокировать конфигурацию, чтобы не разрешались глаголы, задав параметр allowUnlisted="false". Затем перечислите глаголы, которые необходимо явно разрешить, в этом случае GET.

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <verbs
       allowUnlisted="false"
                  >
     <add verb="GET" allowed="true" />
    </verbs>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Фильтрация на основе последовательностей URL-адресов

Эта функция определяет список последовательностей, которые IIS отклоняют, когда он является частью запроса. Если служба IIS отклоняет запрос для данной функции, код ошибки, который регистрируется в журнале, - 404.5. Это соответствует функции DenyUrlSequences в UrlScan.

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

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

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

Фильтрация скрытых сегментов

Эта функция позволяет определить, какие сегменты являются "доступными". Если IIS отклоняет запрос на основе этой функции, регистрируется код ошибки 404.8. Эта функция является новой для IIS 7 и более поздних версий; Он не был частью UrlScan.

Рассмотрим следующий пример, где на сервере есть два URL-адреса:

http://site.com/bin

http://site.com/binary

Предположим, вы хотите разрешить содержимое в двоичном каталоге, но не содержимое в каталоге bin. Если вы используете последовательности URL-адресов и отклоняете последовательность bin, вы отклоните доступ к обоим URL-адресам. Используя приведенную ниже конфигурацию, можно запретить доступ к bin, но содержимое в двоичном файле по-прежнему обслуживается:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <hiddenSegments>
     <add segment="BIN"/>
    </hiddenSegments>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Коды ошибок IIS 7 и выше

В предыдущих версиях можно использовать UrlScan на глобальном уровне для определения политик безопасности, которые вы хотите применить в системах. С помощью IIS 7 и более поздних версий вы можете реализовать эти политики на глобальном уровне, но и по URL-адресу. Таким образом, вы можете использовать все преимущества, предоставляемые новой моделью расширенного делегирования.

В следующей таблице приведена сводка журналов кодов ошибок IIS: