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

Visit link
07 Май / 2018
Author: d1ment Tags: Comments: 0

Bookmark and Share

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

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

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

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

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

DAST – динамический (т.е. требующий выполнения) анализ приложения без доступа к исходному коду и серверной части, по сути BlackBox.

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

IAST – динамический анализ безопасности веб-приложения, с полным доступом к исходному коду, веб-серверу — по своей сути является WhiteBox тестированием.

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

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

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

Разведка

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

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

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

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

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

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

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

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

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

Итого

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




/// There are no comments yet, but you can be the first

/// Leave a Reply

*

code


Sandbox © 2013