В данной статье я расскажу о современных методах и подходах к тестированию безопасности веб-приложений.
Начало исследования
Для успешного тестирования веб-приложений необходимо применять систематизированный подход или методологию. Наиболее известные это OWASP и WASC. Они являются наиболее полными и формализованными методологиями на сегодняшний день.
Далее необходимо определится с веб-приложением — для исследования можно взять последнюю версию одной из бесплатных CMS, и установить в нее уязвимый плагин (уязвимые версии можно скачать с сайта exploit-db.com).
Методы тестирования
Т.к. мы не являемся веб-разработчиками данного приложения, мы пропустим этап тестирования при создании архитектуры и разработки приложения (но стоит отметить что они важны — при разработке).
Есть несколько принципов тестирования, которые мы можем применить:
DAST – динамический (т.е. требующий выполнения) анализ приложения без доступа к исходному коду и серверной части, по сути BlackBox.
SAST – статический (т.е. не требующий выполнения) анализ приложения с доступом к исходному коду веб-приложения и к веб-серверу, по сути это анализ исходного кода по формальным признакам наличия уязвимостей и аудит безопасности сервера.
IAST – динамический анализ безопасности веб-приложения, с полным доступом к исходному коду, веб-серверу — по своей сути является WhiteBox тестированием.
Анализ исходного кода – статический или динамический анализ с доступом к исходному коду без доступа к серверному окружению.
Эти методы полностью подойдут для тренировки навыков выявления уязвимостей веб-приложения при наличии у вас доступа к веб-приложению, либо частиноч, если вы исследуете веб-приложение, к примеру, при участии в программе BugBounty.
Основные этапы
Для полноты тестирования необходимо стараться следовать нижеприведенным рекомендациям кастомизирую те или иные этапы в зависимости от веб-приложения.
Разведка
- Сканирование портов.
- Сканирование поддоменов.
- Исследование видимого контента.
- Поиск скрытого контента (директорий, файлов)
- Определение платформы и веб-окружения.
- Определение форм ввода.
Контроль доступа
- Проверка средств аутентификации и авторизации.
- Определение требований парольной политики.
- Тестирование подбора учетных данных.
- Тестирование восстановления учетной записи.
- Тестирование функций сохранения сессии.
- Тестирование функций идентификации учетной записи.
- Проверка полномочий и прав доступа.
- Исследования сессии (время жизни, сессионный токены, признаки, попытки одновременной работы и т.д.)
- Проверка CSRF.
Фаззинг параметров
- Тестирование приложения к различному виду инъекций (SQL, SOAP, LDAP, XPATH и т.д.)
- Тестирование приложения к XSS-уязвимостям.
- Проверка HTTP заголовков.
- Проверка редиректов и переадресаций.
- Проверка выполнения команд ОС.
- Проверка локального и удаленного инклуда.
- Проверка к внедрению XML-сущностей.
- Проверка тимплейт-инъекций.
- Проверка взаимодествия веб-сокетов.
Проверки логики работы веб-приложения
- Тестирование логики работы приложения на стороне клиента.
- Тестирования на т.н. «состояние гонки» — race condition.
- Тестирование канала передачи данных.
- Тестирование доступности информации исходя из прав доступа или его отсутствия.
- Проверка возможности дублирования или разделения данных.
Проверка серверного окружения
- Проверка архитектуры сервера.
- Поиск и выявление публичных уязвимостей.
- Проверка серверных учетных записей (службы и сервисы).
- Определение настроек сервера или компонентов (SSL и т.д.).
- Проверка прав доступа.
Итого
Имея план тестирования приложения мы можем шаг за шагом исследовать все его компоненты на наличие тех или иных уязвимостей. Исходя из веб-приложения те или иные пункты могут быть дополнены специфичными для данного приложения проверками.
В следующей статье я расскажу об инструментарии, подходящем для тестирования веб-приложения по данному чек-листу.
Автор: Лука Сафонов
