Web

PWD · 27 Авг 2017

ВСЕ ОСТАЛЬНЫЕ 9 ВИДЕО ТЫК

PWD · 27 Авг 2017

Web - это одна из категорий тасков CTF, включающая в себя анализ получаемых и передаваемых вэб приложению данных, поиск, эксплуатирование уязвимостей и защита от них различных вэб приложений,разнообразный взлом, вэб подмену информации, использование ошибок проектирования в настройке сервера. Например, внедрение SQL-инъекций, XSS-инъекций, PHP-инъекций, проведение "Man-in-the-middle", "Meet-in-the-middle_attack", "Man_in_the_Browser" атак и многого другого. Довольно обширная категория, которая включает в себя разнообразный взлом, подмену информации, использование дырок в настройке сервера - и всё это через сетевое подключение.

Дополнительная информация
Инструменты
__________________________________________________________________
- 1. Web
Кликайте колесом мыши для открытия в отдельной вкладке, следует после перехода по ссылке не много подождать пока загрузится страница.

PWD · 27 Авг 2017

LukaSafonov 17 августа в 13:37 Разработка
Современные методы исследования безопасности веб-приложений

В данной статье я расскажу о современных методах и подходах к тестированию безопасности веб-приложений.

Начало исследования

Для успешного тестирования веб-приложений необходимо применять систематизированный подход или методологию. Наиболее известные это OWASP и WASC. Они являются наиболее полными и формализованными методологиями на сегодняшний день.

Далее необходимо определится с веб-приложением — для исследования можно взять последнюю версию одной из бесплатных CMS, и установить в нее уязвимый плагин (уязвимые версии можно скачать с сайта exploit-db.com).

Методы тестирования

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

Есть несколько принципов тестирования, которые мы можем применить:

DAST – динамический (т.е. требующий выполнения) анализ приложения без доступа к исходному коду и серверной части, по сути BlackBox.
SAST – статический (т.е. не требующий выполнения) анализ приложения с доступом к исходному коду веб-приложения и к веб-серверу, по сути это анализ исходного кода по формальным признакам наличия уязвимостей и аудит безопасности сервера.
IAST – динамический анализ безопасности веб-приложения, с полным доступом к исходному коду, веб-серверу — по своей сути является WhiteBox тестированием.
Анализ исходного кода – статический или динамический анализ с доступом к исходному коду без доступа к серверному окружению.

Эти методы полностью подойдут для тренировки навыков выявления уязвимостей веб-приложения при наличии у вас доступа к веб-приложению, либо частиноч, если вы исследуете веб-приложение, к примеру, при участии в программе BugBounty.

Основные этапы

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

Разведка

Сканирование портов.
Сканирование поддоменов.
Исследование видимого контента.
Поиск скрытого контента (директорий, файлов)
Определение платформы и веб-окружения.
Определение форм ввода.

Контроль доступа

Проверка средств аутентификации и авторизации.
Определение требований парольной политики.
Тестирование подбора учетных данных.
Тестирование восстановления учетной записи.
Тестирование функций сохранения сессии.
Тестирование функций идентификации учетной записи.
Проверка полномочий и прав доступа.
Исследования сессии (время жизни, сессионный токены, признаки, попытки одновременной работы и т.д.)
Проверка CSRF.

Фаззинг параметров

Тестирование приложения к различному виду инъекций (SQL, SOAP, LDAP, XPATH и т.д.)
Тестирование приложения к XSS-уязвимостям.
Проверка HTTP заголовков.
Проверка редиректов и переадресаций.
Проверка выполнения команд ОС.
Проверка локального и удаленного инклуда.
Проверка к внедрению XML-сущностей.
Проверка тимплейт-инъекций.
Проверка взаимодествия веб-сокетов.

Проверки логики работы веб-приложения

Тестирование логики работы приложения на стороне клиента.
Тестирования на т.н. «состояние гонки» — race condition.
Тестирование канала передачи данных.
Тестирование доступности информации исходя из прав доступа или его отсутствия.
Проверка возможности дублирования или разделения данных.

Проверка серверного окружения

Проверка архитектуры сервера.
Поиск и выявление публичных уязвимостей.
Проверка серверных учетных записей (службы и сервисы).
Определение настроек сервера или компонентов (SSL и т.д.).
Проверка прав доступа.

Итого

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

В следующей статье я расскажу об инструментарии, подходящем для тестирования веб-приложения по данному чек-листу.

PWD · 27 Авг 2017

LukaSafonov 22 августа в 13:37 Разработка
Современные методы исследования безопасности веб-приложений: инструментарий

В данной статье я расскажу об инструментарии для тестирования безопасности веб-приложений. Основные этапы и чек-лист работ представлены в предыдущей статье.

Большинство утилит содержится в популярных дистрибутивах тестирования на проникновение: Kali Linux, BlackArch, BackBox Linux. Для тех, у кого нет возможности по тем или иным причинам использовать эти дистрибутивы, я публикую ссылки на github/страницы утилит.

Основные этапы

Для полноты тестирования необходимо стараться следовать нижеприведенным рекомендациям, кастомизируя те или иные этапы в зависимости от веб-приложения. Далее я опишу этапы и утилиты, которые подходят к каждому из них.

Разведка

Сканирование портов. На этом этапе поможет нестареющая классика — nmap. Для тех, кто столкнулся с этой утилитой впервые, необходимо учесть, что по умолчанию nmap сканирует ~1000 портов (первые и популярные выше), а также не сканирует UDP — имейте это в виду.

Сканирование поддоменов. На этом этапе пригодится работа с утилитой dig и понимание AXFR запросов. Также пригодится утилита subbrute.

Исследование видимого контента. Здесь, как не странно, вам пригодятся собственные глаза — для того чтобы визуально исследовать веб-приложение, понять его логику работы. Небольшой хинт: для того, чтобы сделать первоначальную проверку анонимной и не привлекать внимание, используйте кэш поисковых систем и системы типа google.tranlsate.

Поиск скрытого контента (директорий, файлов, информации). На этом этапе пригодятся утилиты dirb, dirsearch, можно воспользоваться инструментами Foca (устарел) и maltego (необходима регистрация, есть платная версия).

Определение платформы и веб-окружения. Здесь необходимо воспользоваться аддоном к браузеру wappalyzer или утилитой whatweb.

Определение форм ввода. На этом этапе можно ограничится визуальным осмотром форм на страницах, выявленных в результате поиска скрытого контента.

Отдельно я бы хотел упомянуть «комбайны» для сбора информации: theharvester и recon-ng — с помощью этих инструментов можно получить довольно много информации — от выявления учетных записей и поддоменов до поиска критичной информации на сайте.

Контроль доступа

На данном этапе требуется как инструментальная, так и ручная проверка требований парольной политики.

Для проверки необходимо провести атаку по словарю, например с помощью hydra или patator, используя заведомо известные учетные данные: таким образом можно выявить защиту от такого рода атак (или ее отсутствие).

Определение требований парольной политики. Здесь ручная проверка логики требований политики. Использование только цифр (например как пин-кода) без защиты от брута — очень плохая идея.

Тестирование восстановления учетной записи. На данном этапе приходится наличие нескольких ссылок или триггеров для сброса пароля (желательно от разных учетных записей). Здесь необходимо будет выявить и определить хеш (частое явление), например с помощью hashID. Далее необходимо произвести сравнение тригеров сброса (например ссылок) с помощью утилит сравнения (например comparer в burp suite).

Тестирование функций сохранения сессии. Тестирование функций идентификации учетной записи. Проверка полномочий и прав доступа. Исследования сессии (время жизни, сессионный токены, признаки, попытки одновременной работы и т.д.) Проверка CSRF. Для этих задач хорошо подойдет mantra — есть версия как в виде firefox, так и chrome сборки.

Фаззинг параметров

Тестирование веб-приложения может быть выполнено как в инструментальном режиме (w3af, vega, arachni, sqlmap, Acunetix, Netsparker и.д.), так и полу-инструментальном — Burp Suite, OWASP ZAP и д.р.

С помощью этих инструментов, как автоматическом, так и в ручном (наиболее точном) режиме можно выявлять следующие уязвимости: инъекции (SQL, SOAP, LDAP, XPATH и т.д.), XSS-уязвимости, редиректы и переадресации — весь спектр уязвимостей веба (OWASP TOP 10).

Проверки логики работы веб-приложения

Тестирование логики работы приложения на стороне клиента. Тестирование на т.н. «состояние гонки» — race condition. Тестирование доступности информации исходя из прав доступа или его отсутствия. Проверка возможности дублирования или разделения данных. На этом этапе нам понадобится хорошо изучить логику работы приложения и эксплуатация с помощью Burp Suite, OWASP ZAP или все той же mantra. Выявление таких уязвимостей в автоматическом режиме практически невозможно (кроме утилит работы с кодом для выявления формальных признаков такого рода уязвимостей и изучения исходного кода).

Проверка серверного окружения

Проверка архитектуры сервера. Поиск и выявление публичных уязвимостей. Проверка серверных учетных записей (службы и сервисы). Определение настроек сервера или компонентов (SSL и т.д.). Проверка прав доступа. Здесь можно воспользоваться как специализированными сканерами (под сервис), так и общеизвестными, например такими как OpenVAS, Armitage/Metasploit.

Итого

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

В комментариях буду рад ответить на ваши вопросы.