Защити свой компьютер на 100% от вирусов и хакеров
Шрифт:
Некоторые компоненты веб-сервера позволяют получать список файлов, даже если это не разрешено в конфигурационных файлах. Обычно это возникает в результате ошибок реализации, когда сервер генерирует список файлов при получении определенного запроса.
Базы данных поисковых машин (Google, Wayback machine) могут содержать кэш старых вариантов сервера, включая списки файлов.
Идентификация приложений (Web Server/Application Fingerprinting). Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, веб-северах и браузерах. Кроме того, эта атака может быть направлена на другие компоненты веб-приложения, например службу каталога, сервер баз данных или используемые технологии программирования. Обычно подобные атаки осуществляют, анализируя:
особенности
заголовки HTTP-ответов;
используемые сервером расширения файлов (ASP или JSP);
значение cookie (ASPSESSION и т. д.);
сообщения об ошибках;
структуру каталогов и используемое соглашение об именах (Windows/UNIX);
интерфейсы поддержки разработки веб-приложений (Frontpage/WebPublisher);
интерфейсы администрирования сервера (iPlanet/Comanche);
версию операционной системы.
Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т. д.). Однако для этих целей могут применяться и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer.
Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнение буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок и, как следствие, общий "шум", производимый атакующим. Данный факт отмечен в 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-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружающих текст их страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в качестве параметра CGI-программы или серверного сценария. В результате злоумышленник может получить исходный код сценариев. Довольно часто к имени запрашиваемого файла добавляются специальные символы – такие как %0 0 – с целью обхода фильтров. Следующие примеры иллюстрируют обратный путь в каталогах вебсервера: