Карта архитектуры приложения

Резюме:
Современные веб-инфраструктуры могут включать сотни веб-приложений, что делает управление конфигурацией и её проверку критически важным этапом при тестировании и внедрении. Даже одна уязвимость может поставить под угрозу всю систему. Важно провести тщательный аудит конфигурации и известных проблем безопасности. Однако перед этим необходимо составить карту сети и архитектуры приложения, чтобы понять, как различные элементы взаимодействуют с веб-приложением и как они влияют на безопасность.

Цели тестирования:
Создать карту приложения на основе проведённых исследований.

Как проводить тестирование:
Для создания карты архитектуры приложения необходимо выяснить, какие компоненты используются для его построения. В простых случаях, например, с обычным PHP-приложением, может быть задействован один сервер. В сложных системах, таких как интернет-банкинг, могут быть использованы несколько серверов: прокси-сервер, веб-сервер, сервер приложений и база данных.

Для получения информации о архитектуре приложения тестировщик может:

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

Тестировщик может задавать вопросы типа: «Есть ли брандмауэр, защищающий веб-сервер?» Это можно проверить с помощью сетевого сканирования и анализа, чтобы понять, фильтруются ли порты сервера.

Также тестировщик может определить наличие прокси-сервера, анализируя баннеры веб-сервера или ответы на запросы, сравнивая их с ожидаемыми. Например, некоторые прокси-серверы или системы предотвращения вторжений (IPS) могут блокировать атаки, отвечая на них иначе, чем сам веб-сервер.

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

Балансировщики нагрузки:
Сетевые балансировщики распределяют трафик между несколькими серверами, чтобы улучшить производительность. Для их обнаружения можно отправить несколько запросов и сравнить ответы. Например, если время на серверах не синхронизировано, можно заметить различия по заголовку Date. Также балансировщики, такие как F5 BIG-IP, могут добавлять специальные куки, например BIGipServer.

Серверы приложений:
Веб-серверы приложений можно обнаружить по характерным заголовкам ответа или по тому, что сервер пытается установить специфические куки (например, JSESSIONID для J2EE серверов). Они могут автоматически изменять URL для отслеживания сессий.

Серверы аутентификации:
Системы аутентификации (например, LDAP, базы данных или RADIUS) труднее обнаружить напрямую, так как они скрыты за приложением.

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