• Открыта запись на вторую часть курса по анонимности и безопасности в сети интернет "Paranoid II" от команды codeby. Анонимные роутеры, Подъём, настройка и администрирование Tor-ноды, Работа с железом ПК, Удаление аппаратных закладок, Минимизация рисков, Авторские разработки и многое другое. Подробнее ...

Статья Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.

larchik

larchik

Grey Team
07.06.2019
132
275
Привет, codeby!

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


Определение фреймворка и веб-приложения.

Каркас (фреймворк) веб-приложений
(Web application framework, WAF) — это каркас, предназначенный для создания динамических веб-сайтов, сетевых приложений, сервисов или ресурсов. Он упрощает разработку и избавляет от необходимости написания рутинного кода. Многие каркасы упрощают доступ к базам данных, разработку интерфейса, и также уменьшают дублирование кода. .

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

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

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

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

- HTTP-заголоки
- cookies
- исходный код веб-страниц приложения
- специфические файлы и папки
- расширения файлов
- сообщения об ошибках


HTTP-заголовки

Самый простой сбособ определить фреймворк — посмотреть на заголовок X-Powered-By в ответе сервера. По традиции будем использовать netcat.
Рассмотрим следующий запрос:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


По заголовку X-Powered-By мы можем предположить, что фреймворк в данном случае — Mono. Однако такой способ определения не всегда позволяет точно определить фреймворк, так как такой заголовок может вообще отсутствовать, если так захотел админ тестируемого приложения, либо намерено показывать неверную информацию.

Например, мы можем получить такой ответ от сервера:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


В ходе тестирования стоит обратить внимание и на другие заголовки в ответе сервера. В следующем примере в заголовке X-Powered-By мы можем видеть версию PHP, но в заголовке X-Generator мы снова определили фреймворк Mono:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.



Cookies

Определение фреймворка по файлам cookies является более надежным способом. Для каждого фреймворка они специфичны.
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


По значению заголовка Set-Cookie в ответе сервера мы можем понять, что используется фреймворк CAKEPHP. Хотя и файлы cookie тоже могут быть изменены администратором сервера и приложения, это менее вероятно, чем изменение заголовка X-Powered-By, поэтому данный способ является более надежным.


HTML-код

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

По исходному коду нашего форума мы можем видеть, что на Codeby используется движок XenForo:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Однако, в коде веб-страниц форума можно найти названия директорий, указывающие на WordPress:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Это не должно сбивать с толку, так как форум ссылается на блог, который находится по адресу codeby.net/blogs и сделан на WordPress, то есть это уже другое веб-приложение.

Несколько сложнее определить фреймворк магазина hack.codeby.net. Внешне он очень похож на OpenCart, что вводит в заблуждение. Если присмотреться к исходникам, то можно обнаружить такие названия директорий в путях, как wa-data, wa-content, wa-apps:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Эти названия указывают на CMS Shop-Script, построеной на фреймворке Webasyst.

Директории на сайте можно попробовать сбрутить с помощью словарей, которые содержат известные для разных фреймворков пути, названия файлов и директорий. Данная техника называется Dirbusting. Для брута можно воспользоваться утилитой dirb:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


В результате сканирования сайта не найдены специфичные для фреймворков и CMS файлы, но найден файл error_log, который мы можем просмотреть и так же определить используемую CMS по путям в нем:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Как видите, в этом файле есть много чего интересного. Раскрытые пути до корня, файлы и директории, используемые плагины и СУБД. Если покопаться, можно найти еще больше.
Словари для брутфорса можно взять тут - или тут - .

Кстати, файл robots.txt так же содержит информацию о возможно используемой CMS:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.



Расширения файлов

URL может включать в себя расширения файлов. Это может помочь определить используемую технологию. Например owasp.org использует PHP:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Следующий сайт, судя по расширению, использует Python:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Microsoft ASP.NET:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.



Автоматизированные инструменты.

WhatWeb

Один из лучших инструментов для определения используемых технологий на тестируемом сайте. Предустановлен в Kali Linux. Поддерживает множество опций, описывать которые тут нет смысла. Подробно о WhatWeb с примерами запуска можно почитать тут - .
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


WhatWeb определил, что Owasp использует движок MediWiki.

Wappalyzer
Wappalyzer — это плагин для браузеров Firefox и Chrome. На скриншоте результат его работы для codeby:

Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.



В ходе этого этапа тестирования лучше использовать несколько разных подходов и инструментов, что бы точнее определить технологию.
Например, несмотря на то, что на форуме Codeby все указывает на движок XenForo, утилита WhatWeb определяет тут WordPress:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Имейте ввиду, что разработчики тестируемого сайта могут намерено запутывать вас, изменяя файлы cookie, HTTP-заголовки, добавляя в исходники пути и названия папок от других платформ, создавая фальшивые страницы (например фальшивую админку) и т.д.


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

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

В простом случае мы можем иметь один физический сервер, на котором расположены веб-сервер и сервер БД и одно веб-приложение, размещенное на веб-сервере.

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

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

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

Обратный прокси-сервер перед веб-сервером можно обнаружить по заголовкам HTTP-ответов. Например непосредственно на обратный прокси указывает заголовок «server: WebSEAL», как на скриншоте ниже:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Если нам известно, какой именно сервер используется в веб-приложении, и известно, как он должен отвечать на некорректные запросы (например ошибкой 404), но при этом нам приходят ответы, отличные от ожидаемых, это так же может указывать на прокси-сервер перед веб-сервером.

Другой пример, когда веб-сервер возвращает набор доступных HTTP-методов, включая TRACE или PUT, но при попытке использования этих методов возвращается ошибка — такое поведение тоже может быть связано с наличием прокси-сервера.

В некоторых случаях прокси-сервер выдает себя таким образом:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


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

Он может быть обнаружен, если, например, между всеми серверами единой инфраструктуры не синхронизировано время. Отправив несколько одинаковых запросов на тестируемый адрес и сравнив ответы, можно увидеть различия во времени в заголовке «Date». Это будет означать, что ответы поступают от разных серверов.

Иногда при использовании балансировщика в ответы сервера могут включаться заголовки, явно указывающие на балансировщик, например балансировщик Alteon добавляет в ответы свои cookies:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


Несколько сложнее обнаружить серверы баз данных, серверы LDAP или сереверы RADIUS, поскольку для тестировщика они будут скрыты самим приложением. Но нужно попробовать.

Большинство современных веб-приложений используют базы данных. Предположение о их наличии можно сделать, взаимодействуя с приложением и наблюдая за его поведением. Например, если вы можете сохранить в приложении какой-то контент и использовать его спустя какое-то время, то вероятно ваш контент сохранился в БД. Однако версию используемой системы управления базами данных вы узнаете, если только будут обнаружены ошибки в приложении, генерируемые самой СУБД, либо при сканировании открытых портов сервера либо при обнаружении других уязвимостей (как в одном из примеров выше, где в файле error_log можно найти строки с ошибками, явно говорящие о MySQL).

Пример того, как может выглядить карта архитектуры приложения в простом случае, вы можете видеть ниже:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.


На этом этап сбора информации можно считать завершенным.

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

А на сегодня все. Всем пока )
 
Последнее редактирование:
larchik

larchik

Grey Team
07.06.2019
132
275
спасибо за ссылку, очень годно. Собирался лечь спать, но теперь надо испытывать ))
Правда это тема для другой статьи, все-таки.
 
H

hamerik

Active member
26.06.2019
35
3
Советую ещё одно дополнение которое сам использую в связке с wappalyzer, определяет ip, dns адреса домена и всё связанное с ними:
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
 
  • Нравится
Реакции: Ondrik8 и larchik
С

Сергей webware

Happy New Year
29.02.2016
4
1
Есть подозрение что автор забросил данный цикл статей, но и на этом огромное спасибо!!!
p.s помнится в одной из первых статей автор упоминал про CherryTree, хотелось бы получить столь ценные заметки))
 
larchik

larchik

Grey Team
07.06.2019
132
275
Есть подозрение что автор забросил данный цикл статей, но и на этом огромное спасибо!!!
p.s помнится в одной из первых статей автор упоминал про CherryTree, хотелось бы получить столь ценные заметки))
Не забросил. Сейчас очень напряженный график. Как разгребу все текущие и неотложные дела, обязательно продолжу.
Спасибо, что ждете )
 
Мы в соцсетях:  ТелеграмВконтактеДзенФейсбукТвиттерЮтуб