Методология тестирования на проникновение веб-приложений по OWASP WSTG

Pre-engagement и Test plan

Профессиональное тестирование на проникновение веб-приложений начинается с условий успеха и условий неудачи. Определяются положительный кейс, отрицательный кейс, пограничный кейс и аналогичная легитимная активность. Таким образом можно выявить как False Negative, так и False Positive.

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

Information gathering и Configuration

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

После настройки запускается контролируемое тестирование с ожидаемыми данными, проверяется, что событие зарегистрировано, что основные поля существуют и что изменение не создало нагрузки или слепого пятна. Каждое изменение сохраняется в версии, с датой, владельцем, причиной и результатом тестирования.

Identity, Authentication и Authorization

При тестировании на проникновение веб-приложений идентификация и авторизация — это два разных вопроса: кто клиент и что ему разрешено делать с ресурсом. Проверяются роли, утверждения, сессии, владение объектами и изменения на протяжении жизненного цикла, а не просто констатируется, что пользователь 'вошел в систему'.

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

Session, Input validation и Business logic

Профессиональное тестирование на проникновение веб-приложений начинается с условий успеха и условий неудачи. Определяются положительный кейс, отрицательный кейс, пограничный кейс и аналогичная легитимная активность. Таким образом можно выявить как False Negative, так и False Positive.

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

Evidence, Reporting и Retest

Профессиональное тестирование на проникновение веб-приложений начинается с условий успеха и условий неудачи. Определяются положительный кейс, отрицательный кейс, пограничный кейс и аналогичная легитимная активность. Таким образом можно выявить как False Negative, так и False Positive.

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

Особые точки проверки

В этом разделе рекомендуется заранее построить целевую карту доказательств. Основными точками проверки являются: Роль и сессия, конечная точка и метод, запрос/ответ, идентификатор объекта, побочный эффект на сервере, ожидаемый контроль и исправление. Этот список не является автоматическим контрольным списком; каждый элемент выбран потому, что он может связывать сущность, действие и время или объяснять легитимное поведение.

• Роль и сессия: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.
• Конечная точка и метод: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.
• Запрос/ответ: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.
• Идентификатор объекта: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.
• Побочный эффект на сервере: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.
• Ожидаемый контроль и исправление: Определите ожидаемое значение, что будет считаться аномалией и какой дополнительный источник подтвердит находку.

Если одна из точек недоступна, следует задокументировать пробел и выбрать альтернативу. Например, если идентификатор процесса нестабилен, можно использовать время, хост, пользователя и родителя; если полезная нагрузка зашифрована, используются метаданные, объем, частота и контекст TLS/DNS.

Рекомендуемый процесс работы

1. Определите Scope и один рабочий вопрос по теме тестирования на проникновение веб-приложений.
2. Запишите необходимые источники данных и доказательства: Роль и сессия, конечная точка и метод, запрос/ответ, идентификатор объекта.
3. Создайте краткую базовую линию нормального поведения или ожидаемого результата.
4. Выполните минимальное тестирование в лабораторной среде и сохраните время, входные и выходные данные.
5. Создайте временную шкалу или сравнительную таблицу и отделите факты от интерпретации.
6. Выполните Pivot к дополнительному источнику, чтобы подтвердить или опровергнуть первоначальное объяснение.
7. Сформулируйте решение, ограничения, рекомендуемое действие и критерии повторного тестирования.

Практический сценарий

Выбранный сценарий — построение плана тестирования для OWASP Juice Shop в лаборатории. Цель упражнения не в демонстрации способности к атаке, а в отработке сбора, сравнения и документирования безопасным способом. Перед началом работы определяются фиктивные данные, временное окно и ожидаемый результат.

По завершении упражнения должен быть представлен продукт, который аналитик или другой тестировщик может проверить: снимок или экспорт доказательства, краткая временная шкала, первоначальное предположение, подтверждающее доказательство, ограничение и рекомендация. Если доказательств недостаточно, правильный вывод заключается в том, что сценарий не был доказан.

Практический Checklist

• ✓Проверьте и задокументируйте: Роль и сессию.
• ✓Проверьте и задокументируйте: Конечную точку и метод.
• ✓Проверьте и задокументируйте: Запрос/ответ.
• ✓Проверьте и задокументируйте: Идентификатор объекта.
• ✓Проверьте и задокументируйте: Побочный эффект на сервере.
• ✓Проверьте и задокументируйте: Ожидаемый контроль и исправление.
• ✓Укажите часовой пояс, версию инструмента и время сбора.
• ✓Сохраните необработанные данные перед фильтрацией или изменением.
• ✓Опишите, что обнаруженное доказывает и что до сих пор неизвестно.
• ✓Определите владельца и следующее действие с датой.

Распространенные ошибки

• Проверять только Status code.
• Полагаться на изменение Client-side.
• Использовать опасный Payload.
• Не проверять разные Roles.
• Игнорировать бизнес-логику.
• Сообщать без чистых Request/Response.

Заключение и CTA

Методология тестирования на проникновение веб-приложений по OWASP WSTG — это тема, которая связывает технические знания с рабочей дисциплиной. Начните с вопроса, собирайте только релевантные доказательства, сохраняйте контекст и время, и выбирайте действие, которое можно оправдать и перепроверить.

На курсе Cybersecurity & AI от HPI эти принципы отрабатываются с помощью систем, журналов и лабораторий. Естественным продолжением является переход к связанным статьям, выполнение лабораторного упражнения и сохранение результата как части профессионального портфолио.

Вопросы и ответы