Современные методы исследования безопасности веб-приложений

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

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

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

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

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

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

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

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

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

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

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

Разведка

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

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

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

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

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

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

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

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

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

Итого

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

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

Автор: Лука Сафонов

Источник ^[1]