[Перевод] OWASP Web Security Testing Guide: как улучшить защищённость web-приложений
Open Web Application Security Project (OWASP) — одна из самых известных организаций, целью которой является улучшение защищённости приложений. Большинство специалистов в области информационной безопасности знакомы с OWASP Top Ten. У OWASP есть множество других проектов для различных этапов жизненного цикла разработки программного обеспечения (SDLC).
В предыдущей статье на Хабр я рассказывал о стандарте OWASP ASVS, в котором перечислены требования к безопасности web-приложений. А как убедиться в том, что эти требования выполняются? Ответ на этот вопрос даёт Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, перевод которого я хотел бы представить вашему вниманию.
Место ASVS и WSTG в структуре безопасного SDLC (из OWASP SAMM)
Что из себя представляет WSTG?
За более чем 20 лет своей работы OWASP накопил огромный багаж знаний в области безопасности приложений. Результат — Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, с которым может свободно ознакомиться каждый. В нём описываются приёмы, методики, инструменты и ресурсы для тестирования наиболее распространённых уязвимостей web-приложений.
Текущая версия WSTG — 4.2. Также доступны материалы для будущей версии 5.0, которая в настоящее время разрабатывается и постоянно обновляется. Надо сказать, что это не первая попытка перевода, но полной версии WSTG я в свободном доступе не нашёл, решил взяться за текущую, актуальную на 2022 г. (latest).
Какое место занимает WSTG в методике тестирования OWASP?
Типичный цикл безопасной разработки приложений
WSTG фокусируется на этапе развёртывания и, в частности, тестировании на проникновение. В различных сценариях для поиска уязвимостей предлагаются разные методы тестирования (т.н. «белого», «серого» и «чёрного ящика»), однако красной нитью проходит мысль о необходимости сбалансированного подхода, сочетающего всё перечисленное, т. к. каждый метод имеет свою область применения, преимущества и недостатки (однако, на тест надейся, а Дейкстру не забывай).
Сочетание преимуществ и нивелирование недостатков разных методов требует сбалансированного подхода
Области тестирования WSTG
WSTG охватывает следующие области тестирования:
Сбор информации: получение информации о web-сервере, приложении и его архитектуре.
Тестирование управления конфигурациями и развёртыванием: определение конфигурации сети и приложений, используемые HTTP-методы, а также относительно новые сценарии, такие как захват поддомена и облачные хранилища.
Тестирование управления идентификацией: определение ролей (RBAC), регистрацию пользователей и инвентаризацию учётных записей.
Тестирование аутентификации: выявление учётных данных по умолчанию, блокировка пользователя, парольная политика, МФА и т.д.
Тестирование авторизации: обход каталогов, повышение привилегий, IDOR и OAuth.
Тестирование управления сессиями: тесты фиксации и перехвата сессий, атрибуты cookie, CSRF и JWT.
Тестирование контроля входных данных: XSS-атаки, различные типы инъекций, включая SQL (с учётом специфики СУБД), XML, SSTI, LFI/RFI, SSRF и др.
Тестирование обработки ошибок.
Тестирование криптографии: TLS и шифрование.
Тестирование бизнес-логики: поиск нарушений в бизнес-логике. Например, в бизнес-процессе необходимо, чтобы пользователь выполнил шаг 1, а затем шаг 2. Если мы сможем выполнить шаг 2, не выполняя шага 1 — это нарушение логики. Конкретного способа, как найти такие уязвимости нет, но WSTG предлагает как протестировать их наличие.
Тестирование на стороне клиента: сценарии DOM-XSS, HTML-, JS- и CSS-инъекции, CORS, WebSockets, кликджекинг и др.
Тестирование API: GraphQL.
Не менее интересны и приложения к Руководству:
Информации и ресурсов в WSTG много — несколько сотен страниц в pdf-версии. Ошибок в переводе соответственно тоже немало — пишите, пожалуйста, о них в ЛС.
С чего начать работу с WSTG?
Руководство поначалу может казаться пугающим из-за объёма — включает порядка ста сценариев тестирования. Давайте обсудим способы внедрения WSTG в SDLC конкретной организации.
Обучение безопасной разработке: команды разработки и тестирования должны регулярно практиковаться в сценариях тестирования, а также изучать инструменты. Хотя WSTG и ориентирован на тестирование, Руководство включает в себя рекомендации для разработчиков.
Расставьте приоритеты для тестов: невозможно применить всё и сразу. Во-первых, надо выбрать сценарии, которые уместны в контексте вашей ситуации и могут предотвратить наиболее серьёзные из известных вам рисков. Дайте команде время на освоение, а затем постепенно добавляйте тесты в свой SDLC в соответствии с имеющимися ресурсами.
Как определить, какие сценарии тестирования подходят для начала внедрения WSTG? Первые кандидаты:
Тесты, связанные с архитектурой ваших приложений и информацией, которую вы защищаете. Например, если в приложении используется протокол OAuth, то важно включить сценарий Тестирование уязвимостей в Oauth, а если есть процесс оплаты, то нужен сценарий Тестирование платёжных функций.
Тесты, относящиеся к OWASP Top 10. Они охватывают наиболее распространённые угрозы для web-приложений.
Тесты, в которых у команды больше опыта. По мере изучения, можно добавлять новые.
Внедряйте WSTG вместе с «родственными» проектами OWASP. Например, ASVS. С ним связаны Proactive Top 10 и серия памяток, содержащих практические рекомендации. Идея состоит в том, чтобы улучшить не отдельно взятый этап SDLC, а столько, сколько вы сможете себе позволить при имеющихся ресурсах.
Внедрение WSTG совместно с использованием требований из стандарта ASVS
Назначьте «WSTG-чемпиона» — участника команды, который имеет больше опыта в WSTG. Эта роль поможет распространить и внедрить WSTG в вашей компании.
Регулярно контролируйте результаты и сообщайте о них руководству. Динамика таких показателей, как «количество обнаруженных уязвимостей по уровням критичности», может показать, насколько хорошо команда находит реальные уязвимости и как практика тестирования безопасности улучшает защищённость ваших web-приложений.
Кстати, эти рекомендации применимы к большинству проектов в области кибербезопасности.
Уровни зрелости процессов тестирования в соответствии с моделью OWASP SAMM
WSTG для самостоятельных тестировщиков
Ресурсы WSTG могут пригодиться экспертам кибербезопасности, исследователям уязвимостей и студентам. Для проведения тестов в лабораторных условиях можно быстро развернуть виртуалку с дистрибутивом Samurai WTF (Web Testing Framework, а вы что подумали?), в которой инструменты тестирования уживаются с зоопарком из уязвимых web-приложений.
Samurai WTF v5.2
Пентестерам и Bug Bounty-хантерам рекомендуется дополнять тесты другими ресурсами и актуальными публикациями об уязвимостях и новых методах тестирования.
Автоматизация тестирования web-приложений
WSTG представляет собой структурированный источник информации в формате wiki, предназначенный для того, чтобы снизить вероятность уязвимостей в коде и обеспечить киберустойчивость приложения после развёртывания. Устранение дефектов на ранних стадиях является проблемой, с которой сталкиваются все разработчики. На пути к созданию защищённых приложений появился целый ряд технологий автоматизации тестирования. Использование инструментов статического анализа кода (SAST) позволяет выявлять уязвимости в исходном коде приложений. Динамическое тестирование приложений (DAST) обеспечивает взгляд на запущенное приложение «снаружи» до его вывода в эксплуатацию. Интерактивное тестирование (IAST) как симбиоз SAST и DAST, применяется для анализа дефектов в работающих приложениях в режиме реального времени с помощью встроенных в приложение сенсоров (агентов), и проводит автотесты в среде разработки или тестирования (например, Selenium). Список инструментов автоматизации с открытым исходным кодом также есть на сайте OWASP.
Применение инструментов автоматизации тестирования по этапам SDLC
Все эти возможности позволяют улучшить защищённость приложений. Один из проектов OWASP — Benchmark, позволяет оценить точность, охват и производительность инструментов на почти трёх тысячах примерах уязвимостей, из которых половина — настоящие, а остальные — ложные. Можно воспринимать это как призыв к действию для разработчиков инструментов: у кого уже есть функциональность тестирования на соответствие требованиям ASVS и по сценариям WSTG?
