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

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


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

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

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


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

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

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

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

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


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

Разведка


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

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


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

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


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

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


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

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


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

Итого


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

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

Комментарии (10)