Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о составлении архитектурной карты веб-приложения.

Предыдущие статьи:

1. Тестирование: введение и задачи
2. Сбор информации с помощью поисковых систем
3. Определение веб-сервера
4. Поиск информации в метафайлах веб-сервера
5. Определение веб-приложений на сервере
6. Поиск утечек информации в комментариях и метаданных
7. Определение точек входа веб-приложения
8. Составление карты веб-приложения
9. Определение фреймворка веб-приложения
10. Определение веб-приложения

Составление карты архитектуры веб-приложения
Резюме

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

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

Как тестировать

Архитектура приложения должна быть задокументирована (построена карта) для понимания, какие компоненты используются в работе веб-приложения. В небольших конфигурациях, например при использовании простых CGI приложений, может быть использован один сервер, на котором функционирует веб-сервер, исполняющий С, Perl или CGI приложения, и возможно присутствие какого-либо механизма аутентификации.

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

Сведения об архитектуре приложения могут быть получены от разработчиков в документальной форме или через интервью. Но такие сведения бывает сложно получить просто проводя “слепое” тестирование на проникновение.

В случае проведения “слепого” тестирования, тестировщик начинает с предположения о простой конфигурации (единичный сервер). По мере получения новой информации о приложении, карта архитектуры приложения расширяется. Тестировщик начинает со следующих простых вопросов: “Присутствует ли файрвол, защищающий веб-приложение?”  Ответ на такой вопрос может быть получен по результатам сканирования сети веб-сервера и анализа, фильтруются ли сетевые порты на уровне сети ( нет ответа или ICMP статус unreachable получен) или же сервер напрямую подключен к сети Интернет (возвращает RST пакеты для всех не-слушаемых портов) Такой анализ может быть расширен, например, можно попытаться определить тип используемого файрвола на основе сетевых пакетов. Это SPI-файрвол (Stateful Packet Inspection) или это просто списки контроля доступа (Access Control List или ACL) на роутере? Как он сконфигурирован? Можно ли его обойти?

Также необходимо выяснить наличие реверсивного прокси-сервера перед веб-сервером, это можно сделать с помощью анализа баннера веб-сервера, в котором может быть напрямую указано наличие реверсивного прокси-сервера (например если возвращается строка “WebSEAL”) Также наличие реверсивного прокси можно определить сравнивая ответы веб-сервера на запросы с ожидаемым поведением( ожидаемые ответы) Например, некоторые реверсинвыне прокси могут выступать в качестве систем предотвращения вторжений (intrusion prevention system), блокируя известные атаки на веб-сервер. Если известно, что веб-сервер отвечает статус-сообщением 404 на запрос несуществующей страницы, и возвращает другие сообщения об ошибках при попытке проведения типичных атак, которые например используются в сканнерах уязвимостей, это может сигнализировать о наличии реверсивного прокси (или файрвола на уровне приложения) который фильтрует запросы и возвращает отличные от стандартных страницы ошибок. Другой пример: если веб-сервер возвращает набор разрешенных HTTP методов (включая TRACE) но при вызове конкретного метода возвращает ошибку — скорей всего что-то блокирует такие запросы.

В некоторых случаях, защитные системы сообщают о себе в ответах:


GET /web-console/ServerInfo.jsp%00 HTTP/1.0
HTTP/1.0 200
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83
<TITLE>Error</TITLE>
<BODY>
<H1>Error</H1>
FW-1 at XXXXXX: Access denied.</BODY>


Реверсивные прокси также могут выступать в роли кеширующих прокси для увеличения производительности серверов приложений. Определить такие прокси-серверы можно по анализу заголовков. Также такие прокси можно определить по таймингу запросов-ответов, которые должны быть закешированы сервером, сравнивая время ответа на первый запрос со временем ответа на последующие запросы.

Еще один элемент, наличие которого можно определить в целевой архитектуре —  сетевой балансировщик нагрузки. Обычно, подобные системы используются для балансировки нагрузки определенного TCP\IP порта между несколькими серверами по определенному алгоритму. Таким образом, детектирование этого элемента архитектуры требует изучения нескольких запросов и сравнения ответов для определения того, пришли ли эти ответы от одного веб-сервера или от разных. Например, на основе времени в поле Date, если серверы не синхронизированы. Некоторые балансировщики нагрузки вставляют дополнительную информацию в пакеты данных, что позволяет определить их наличие, например балансировщик Alteon WebSystems вставляет строку “AlteonP” в куки.

Веб-серверы приложений обычно довольно легко обнаружить. Зачастую, серверы приложений сами обрабатывают поступающие веб-запросы (а не веб-сервер), поэтому заголовки ответов могут значительно отличаться ( различные значения в полях заголовка, появление дополнительных полей). Еще один способ определить наличие сервера приложений — посмотреть, не добавляет ли веб-сервер куки, которые могут идентифицировать сервер приложений (например, JSESSIONID используемые некоторыми J2EE серверами).

Определение бек-эндов аутентификации (LDAP, реляционные базы данных или RADIUS серверы) вне периметра — не такая уж простая задача, так как зачастую они скрыты самим веб-приложением.

Использование в бек-энде базы данных можно зафиксировать просто исследуя веб-приложение. Если в приложении много динамического контента, который генерируется “на лету”, весьма вероятно что данные извлекаются приложением из какой-либо базы данных. Иногда, пролить свет на возможное использование базы данных позволяет механизм взаимодействия с приложением. Например, приложение онлайн магазина, использующее числовые идентификаторы (“id”) при просмотре различных товаров. Однако, при проведении слепого тестирования приложения, знания об используемой базе данных можно получить только из присутствующих ошибок в приложении, таких как некорректная обработка исключений или SQL инъекции.

Справочные материалы

• 1. WebSEAL, также известный как Tivoli Authentication Manager, реверсивный прокси от IBM, являющийся частью Tivoli framework.
• 2. Инструменты администрирования для веб-сервера Apache (NetLoony)