Защити свой компьютер на 100% от вирусов и хакеров. Олег Михайлович Бойцев
Читать онлайн книгу.
специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок и, как следствие, общий "шум", производимый атакующим. Данный факт отмечен в HTTP RFC 2068, рекомендующим, чтобы значение заголовка Server HTTP-ответа являлось настраиваемым параметром. Пример: сообщения об ошибках – ошибка 404 сервером Apache обозначается фразой Not Found, в то время как IIS 5.0 отвечает сообщением Object Not Found (листинг 1.14).
Листинг 1.14. Сообщение об ошибке, формируемое сервером Apache
# telnet target1.com 80
Trying target1.com…
Connected to target1.com.
Escape character is '^]'.
HEAD /non-existent-file.txt HTTP/1.0
HTTP/1.1 404 Not Found
Date: Mon, 07 Jun 2004 14:31:03 GMT
Server: Apache/1.3.29 (UNIX)
mod_perl/1.29
Connection: close
Content-Type: text/html; charset=iso-
8859-1
Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров (Content-Length в IIS или Content-length в Netscape-Enterprise/6.0).
Несмотря на требования HTTP RFC, существуют семантические особенности при генерации заголовков различными серверами. Например, Apache передает параметр
Date перед значением заголовка Server, в то время как IIS использует обратный порядок. Порядок значений параметров также может отличаться. Например, при обработке запроса OPTIONS Apache возвращает только параметр Allow, в то время как IIS дополнительно включает параметр Public.
Аналогичным образом может анализироваться наличие опциональных заголовков (Vary, Expires и т. д.) и реакция сервера на неверные запросы (GET //, GET/%2f и т. д.).
Утечка информации (Information Leakage). Эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы. Ценные, с точки зрения злоумышленника, данные могут содержаться в комментариях HTML, сообщениях об ошибках или просто присутствовать в открытом виде. Существует огромное количество ситуаций, в которых может произойти утечка информации. Необязательно она приводит к возникновению уязвимости, но часто дает атакующему прекрасное пособие для развития атаки. С утечкой важной информации могут возникать риски различной степени, поэтому необходимо минимизировать количество служебной информации, доступной на клиентской стороне. Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL-запросах, названиях ключевых процессов и программ сервера. Часто разработчики оставляют комментарии в HTML-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.
Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т. д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты веб-приложений и переходят в область