Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения. |
||
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
2022-09-10 04:18 Привет, codeby! Как стать хакером и Как взломать сайт: беглое знакомство с OWASP Testing Guide Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере. Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения. Каркас (фреймворк) веб-приложений (Web application framework, WAF) — это каркас, предназначенный для создания динамических веб-сайтов, сетевых приложений, сервисов или ресурсов. Он упрощает разработку и избавляет от необходимости написания рутинного кода. Многие каркасы упрощают доступ к базам данных, разработку интерфейса, и также уменьшают дублирование кода. Википедия. Существует очень большое количество разных фреймворков. Приводить в этой статье списки фреймворков и их описания не вижу смысла, так как их очень много. Информацию о некоторых из них вы можете получить в сравнительных таблицах. Если тестировщику известен фреймворк тестируемого приложения, и он уже знаком с этим фреймворком (может быть тестировал ранее, или сам разрабатывал на нем приложения), то он получает некоторое преимущество. Как и в случае с веб-сервером, фреймворк может иметь известные уязвимости или неверную конфигурацию, что в конечном счете может привести ко взлому тестируемого сайта. Информация об используемом фреймворке может быть получена путем анализа некоторых точек веб-приложения, в которых могут находиться маркеры, указывающие на конкретный фреймворк, и анализа структуры приложения в целом. Инструменты для автоматического определения фреймворка находят эти маркеры и сравнивают их с записями в своей базе данных. Для более точного определения обычно сравниваются сразу несколько маркеров.
Рапространенные места для поиска маркеров, указывающих на конкретный фреймворк: - HTTP-заголоки - cookies - исходный код веб-страниц приложения - специфические файлы и папки - расширения файлов - сообщения об ошибках HTTP-заголовки Самый простой сбособ определить фреймворк — посмотреть на заголовок X-Powered-By в ответе сервера. По традиции будем использовать netcat. Рассмотрим следующий запрос: Например, мы можем получить такой ответ от сервера: Определение фреймворка по файлам cookies является более надежным способом. Для каждого фреймворка они специфичны. HTML-код Этот метод основан на поиске определенных шаблонов в исходном коде веб-страниц. Обычно в исходниках содержится много информации, помогающей определить фреймворк. Одним из распространенных маркеров являются комментарии в исходном коде, которые добавляются в код автоматически и непосредственно ведут к раскрытию версии фреймворка. Так же можно найти специфичные пути к файлам и папкам, присущие конкретному фреймворку или CMS, например пути к файлам .css и .js. Кроме того, названия переменных в скриптах так же могут указывать на определенный фреймворк. По исходному коду нашего форума мы можем видеть, что на Codeby используется движок XenForo: Несколько сложнее определить фреймворк магазина hack.codeby.net. Внешне он очень похож на OpenCart, что вводит в заблуждение. Если присмотреться к исходникам, то можно обнаружить такие названия директорий в путях, как wa-data, wa-content, wa-apps: Директории на сайте можно попробовать сбрутить с помощью словарей, которые содержат известные для разных фреймворков пути, названия файлов и директорий. Данная техника называется Dirbusting. Для брута можно воспользоваться утилитой dirb: URL может включать в себя расширения файлов. Это может помочь определить используемую технологию. Например owasp.org использует PHP: WhatWeb Один из лучших инструментов для определения используемых технологий на тестируемом сайте. Предустановлен в Kali Linux. Поддерживает множество опций, описывать которые тут нет смысла. Подробно о WhatWeb с примерами запуска можно почитать тут - WhatWeb - Инструменты Kali Linux. Wappalyzer — это плагин для браузеров Firefox и Chrome. На скриншоте результат его работы для codeby: Карта архитектуры приложения. Одна комплексная и разнородная инфраструктура может включать в себя десятки или даже сотни взаимосвязанных веб-приложений, веб-серверов, систем управления базами данных и так далее. Требуется всего лишь одна уязвимость, что бы подорвать безопасность всей инфраструктуры. Казалось бы даже несущественные проблемы в одном компоненте инфраструктуры могут перерасти в серьезные проблемы для всех остальных частей системы. Поэтому так важно определить все компоненты инфраструктуры, понять, как они взаимодействуют с тестируемым приложением и как они влияют на его безопасность. В простом случае мы можем иметь один физический сервер, на котором расположены веб-сервер и сервер БД и одно веб-приложение, размещенное на веб-сервере. Схема может быть такой:
В более сложных случаях инфраструктура может включать балансироващик нагрузки, обратный прокси-сервер, веб-сервер, сервер приложений, сервер БД, сервер LDAP. Все эти элементы могут быть физически разграничены, находиться в разных сетях, иметь межсетевые экраны между ними. Получение информации об архитектуре приложения может быть сложным делом в случае тестирования методом Black Box. В таком случае пентестер сначала предполагает простую структуру, состоящую из одного сервера. В дальнейшем, при получении дополнительной информации в ходе тестирования, тестировщик ставит под сомнение свое первое предположение и расширяет карту архитектуры. Нужно задавать себе простые вопросы и стараться ответить на них: существует ли между клиентом и сервером брандмауэр, защищающий веб-сервер? Такая информация может быть получена в результате сканирования портов сервера, анализа ответов от него. Какой это тип брандмауэра? Есть ли между клиентом и сервером другое физическое устройство? Как оно настроено? Можно ли его обойти? Обратный прокси-сервер перед веб-сервером можно обнаружить по заголовкам HTTP-ответов. Например непосредственно на обратный прокси указывает заголовок «server: WebSEAL», как на скриншоте ниже: В некоторых случаях прокси-сервер выдает себя таким образом: Иногда при использовании балансировщика в ответы сервера могут включаться заголовки, явно указывающие на балансировщик, например балансировщик Alteon добавляет в ответы свои cookies: Пример того, как может выглядить карта архитектуры приложения в простом случае, вы можете видеть ниже: А на сегодня все. Всем пока ) Источник: codeby.net Комментарии: |
|