инфраструктуре позволяет снизить количество ошибок и, как следствие, общий 'шум', производимый атакующим. Данный факт отмечен в 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-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.
Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т. д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты веб-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т. д. Данный пример хорошо поясняют три основные категории утечки информации: комментарии разработчиков, сообщения об ошибках и отображение конфиденциальной информации. Ниже приведен комментарий разработчиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер VADER:
<TABLE border='0' cellPadding='0' cellSpacing='0'
height='59' width='591'>
<TBODY>
<TR>
<! – If the image files are missing,
restart VADER ->
<TD bgColor='#ffffff' colSpan='5'
height='17' width='587'> </TD>
</TR>
Подробные сообщения об ошибках могут возникать в результате специально сформированного запроса. Ниже приведен пример сообщения, типичного для ошибки, возникающей в результате SQL-запроса. Для реализации атаки с внедрением кода SQL обычно требуется знание структуры запросов, осуществляемых веб-сервером. Сведения, содержащиеся в передаваемой подробной информации об ошибке, могут быть использованы для построения атакующим корректных запросов к серверу баз данных.
Ниже приведено сообщение, выдаваемое сервером при вводе символа апострофа (') в качестве имени пользователя (листинг 1.15).
Листинг 1.15. Сообщение сервера об ошибке при вводе недопустимого символа
An Error Has Occurred.
Error Message:
System.Data.OleDb.OleDbException: Syntax error (missing
operator) in query expression 'username = ''' and password =
'g''. at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling (
Int32 hr) at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult
( tagDBPARAMS dbParams, Object& executeResult) at
В первой части сообщения выводится часть запроса, вызвавшего ошибку. По этой информации злоумышленник может получить информацию об используемых параметрах запроса и месте запроса, в котором осуществляется внедрение кода.
Обратный путь в директориях
Данная техника атак направлена на получение доступа к файлам, директориям и командам, находящимся вне основной директории веб-сервера. Злоумышленник может манипулировать параметрами URL с целью получить доступ к файлам или выполнить команды, располагаемые в файловой системе веб- сервера.
При подобных атаках потенциально уязвимо любое устройство, имеющее веб-интерфейс. Многие веб- серверы ограничивают доступ пользователя определенной частью файловой системы, обычно называемой web document root или CGI root. Эти директории содержат файлы, предназначенные для пользователя, и программы, необходимые для получения доступа к функциям веб-приложения. Большинство базовых атак, эксплуатирующих обратный путь, основаны на внедрении в URL-символов ../, чтобы изменить расположение ресурса, который будет обрабатываться сервером. Поскольку большинство веб-серверов фильтруют эту последовательность, злоумышленник может воспользоваться альтернативными кодировками для представления символов перехода по директориям. Популярные приемы включают использование альтернативных кодировок, например Unicode (..%u2216 или ..%c0%af), использование обратного слэша (..) в Windows-серверах, символов URLEncode (%2e%2e%2f) или двойной кодировки URLEncode (..%2 55c). Даже если веб-сервер ограничивает доступ к файлам определенным каталогом, эта уязвимость может возникать в сценариях или CGI-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружающих текст их страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в
