Привет, codeby!
Сегодня мы научимся определять фреймворк и веб-приложение, а так же составим карту архитектуры приложения. На этом «разведка перед боем» будет завершена и следующих статьях приступим непосредственно к тестированию.
Определение фреймворка и веб-приложения.
Каркас (фреймворк) веб-приложений (Web application framework, WAF) — это каркас, предназначенный для создания динамических веб-сайтов, сетевых приложений, сервисов или ресурсов. Он упрощает разработку и избавляет от необходимости написания рутинного кода. Многие каркасы упрощают доступ к базам данных, разработку интерфейса, и также уменьшают дублирование кода.
Существует очень большое количество разных фреймворков. Приводить в этой статье списки фреймворков и их описания не вижу смысла, так как их очень много. Информацию о некоторых из них вы можете получить в
Если тестировщику известен фреймворк тестируемого приложения, и он уже знаком с этим фреймворком (может быть тестировал ранее, или сам разрабатывал на нем приложения), то он получает некоторое преимущество. Как и в случае с веб-сервером, фреймворк может иметь известные уязвимости или неверную конфигурацию, что в конечном счете может привести ко взлому тестируемого сайта.
Информация об используемом фреймворке может быть получена путем анализа некоторых точек веб-приложения, в которых могут находиться маркеры, указывающие на конкретный фреймворк, и анализа структуры приложения в целом. Инструменты для автоматического определения фреймворка находят эти маркеры и сравнивают их с записями в своей базе данных. Для более точного определения обычно сравниваются сразу несколько маркеров.
Рапространенные места для поиска маркеров, указывающих на конкретный фреймворк:
- 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 по путям в нем:
Как видите, в этом файле есть много чего интересного. Раскрытые пути до корня, файлы и директории, используемые плагины и СУБД. Если покопаться, можно найти еще больше.
Словари для брутфорса можно взять тут - danielmiessler/SecLists или тут - fuzzdb-project/fuzzdb.
Кстати, файл 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-методов и некоторые другие задачи.
А на сегодня все. Всем пока )
Сегодня мы научимся определять фреймворк и веб-приложение, а так же составим карту архитектуры приложения. На этом «разведка перед боем» будет завершена и следующих статьях приступим непосредственно к тестированию.
Как стать хакером и Как взломать сайт: беглое знакомство с OWASP Testing Guide
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Определение фреймворка и веб-приложения.
Каркас (фреймворк) веб-приложений (Web application framework, WAF) — это каркас, предназначенный для создания динамических веб-сайтов, сетевых приложений, сервисов или ресурсов. Он упрощает разработку и избавляет от необходимости написания рутинного кода. Многие каркасы упрощают доступ к базам данных, разработку интерфейса, и также уменьшают дублирование кода.
Ссылка скрыта от гостей
.Существует очень большое количество разных фреймворков. Приводить в этой статье списки фреймворков и их описания не вижу смысла, так как их очень много. Информацию о некоторых из них вы можете получить в
Ссылка скрыта от гостей
.Если тестировщику известен фреймворк тестируемого приложения, и он уже знаком с этим фреймворком (может быть тестировал ранее, или сам разрабатывал на нем приложения), то он получает некоторое преимущество. Как и в случае с веб-сервером, фреймворк может иметь известные уязвимости или неверную конфигурацию, что в конечном счете может привести ко взлому тестируемого сайта.
Информация об используемом фреймворке может быть получена путем анализа некоторых точек веб-приложения, в которых могут находиться маркеры, указывающие на конкретный фреймворк, и анализа структуры приложения в целом. Инструменты для автоматического определения фреймворка находят эти маркеры и сравнивают их с записями в своей базе данных. Для более точного определения обычно сравниваются сразу несколько маркеров.
Рапространенные места для поиска маркеров, указывающих на конкретный фреймворк:
- 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 по путям в нем:
Как видите, в этом файле есть много чего интересного. Раскрытые пути до корня, файлы и директории, используемые плагины и СУБД. Если покопаться, можно найти еще больше.
Словари для брутфорса можно взять тут - danielmiessler/SecLists или тут - fuzzdb-project/fuzzdb.
Кстати, файл 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-методов и некоторые другие задачи.
А на сегодня все. Всем пока )
Последнее редактирование:
