Первая оценка веб-приложения

Это руководство проведёт вас через реальную оценку безопасности веб-приложения — от запуска Cyberstrike до проверенных результатов по уязвимостям. Мы протестируем веб-приложение с двумя ролями пользователей (администратор и обычный пользователь) для поиска проблем авторизации, инъекций и логических ошибок.

1. Запуск Cyberstrike

cyberstrike

TUI открывается с загруженным первичным агентом cyberstrike, готовым к вводу.

2. Начало сессии

Введите что угодно для начала сессии. Опишите, что вы тестируете:

> I'm testing https://app.example.com — it's a SaaS platform with admin and regular user roles.
  I have credentials for both. Let's find auth bypass, IDOR, injection, and business logic issues.

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

3. Переименование сессии

Нажмите Ctrl+R для переименования сессии во что-то осмысленное:

example-com-web-assessment

Это поможет найти её позже в /sessions.

4. Запуск HackBrowser

Выполните слэш-команду /hackbrowser. Откроется диалог запуска с полями:

• Целевой URL — введите https://app.example.com
• Учётные данные — добавьте две: userA (администратор) и userB (обычный пользователь)
• Scope — по умолчанию *.example.com, скорректируйте, если API находится на другом домене
• Шаги — сколько страниц сканировать (по умолчанию 50)

Подтвердите диалог. Поскольку вы указали учётные данные, HackBrowser открывается в видимом режиме.

5. Вход как userA

Открывается окно браузера Chromium — это HackBrowser со встроенным расширением телеметрии, которое предоставляет панель UI на каждой странице. Войдите вручную как userA (учётная запись администратора).

После входа нажмите кнопку Record на панели HackBrowser. Это запустит AINavigator — сессию сканирования на основе LLM. ИИ читает дерево доступности страницы, решает, по каким ссылкам переходить, какие формы заполнять и какие кнопки нажимать, автономно перемещаясь по приложению от имени userA.

6. Вход как userB

Второе окно браузера открывается автоматически для userB (обычный пользователь). Войдите вручную с учётными данными userB, затем нажмите Record на его панели.

Теперь HackBrowser сканирует приложение с обеими ролями. Каждый HTTP-запрос помечается учётными данными, которые его выполнили, чтобы конвейер знал, какая роль получила доступ к какой конечной точке.

7. Что происходит дальше

Пока HackBrowser сканирует, остальная часть системы уже работает:

Захват трафика — Каждая пара запрос/ответ поступает в Vortex с полными заголовками, телом и контекстом UI (какие поля формы были только для чтения, скрыты или отключены в момент отправки запроса).

Генерация сигналов — Vortex применяет правила к захваченному трафику и генерирует сигналы: паттерны аутентификации, скрытые параметры, подозрительные формы ответов, доступ к конечным точкам в зависимости от роли.

Диспетчеризация WSTG — wstg-agent читает сигналы и направляет специализированных агентов. Запрос с ID пользователя в пути запускает wstg-authorization для тестирования IDOR. POST с полями формы запускает wstg-input-validation для инъекций. Конечная точка входа запускает wstg-authentication.

Сравнение ролей — Поскольку и userA, и userB сканировали одно приложение, конвейер сравнивает, к каким конечным точкам получила доступ каждая роль, какие элементы UI были видны каждой из них, и держатся ли границы ролей при воспроизведении запросов с другими учётными данными.

Эскалация — После завершения работы специалистов escalation-hunter анализирует все находки для их связывания — среднее IDOR в сочетании с низким обходом ограничения частоты может эскалировать до критического захвата учётной записи.

Триаж — Агент triage независимо воспроизводит HTTP-доказательства для каждого черновика находки. Только находки, подтверждённые воспроизведением, получают статус «проверено». Ложные срабатывания отклоняются. Неоднозначные находки остаются черновиками для вашего рассмотрения.

8. Просмотр находок

После завершения сканирования и тестирования просмотрите результаты:

Формат находки

Каждая находка включает:

FINDING: IDOR in User Profile API
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Severity: High
CWE: CWE-639
Description: GET /api/users/{id} returns full profile data for any user ID
             when accessed with userB credentials (regular user).
Evidence: Replayed GET /api/users/1 with userB token → 200, body contains
          admin user's email and phone number.
Status: triaged (verified by replay)
Recommendation: Enforce ownership check — users should only access their own profile.

Уровни серьёзности

9. Экспорт и публикация

Следующие шаги

• Агенты безопасности — Понимание конвейера WSTG и специализированных агентов
• Возможности — Подробно о HackBrowser, Vortex, Bolt, MCP
• Конфигурация — Настройка scope, разрешений и значений по умолчанию
• Слэш-команды — Полный справочник команд