Перейти к основному содержимому

Web Pentest

Авторизованное тестирование веб-приложений на проникновение — разведка, анализ уязвимостей, эксплуатация с доказательствами и профессиональная отчётность. Адаптирует методологию Шеннона «No Exploit, No Report» с жёсткими ограничениями по области, авторизации и утечке через вспомогательный клиент. Активное тестирование работающих приложений, которыми вы владеете или на которые имеете письменное разрешение.

Метаданные навыка​

ИсточникОпционально — установка: vibeos skills install official/security/web-pentest
Путьoptional-skills/security/web-pentest
Платформыlinux, macos

Справочник: полный SKILL.md​

к сведению

Ниже приведено полное описание навыка, которое VibeOS загружает при его активации. Это инструкции, которые видит агент, когда навык активен.

Тестирование веб-приложений на проникновение

Поэтапный рабочий процесс пентеста для работающих веб-приложений. Адаптирован из пайплайна Шеннона (Keygraph, AGPL — только концепции, код не заимствован). Построен на трёх правилах:

  1. Нет эксплойта — нет отчёта: каждое найденное уязвимость требует воспроизводимого доказательства.
  2. Ограниченная область: каждый активный запрос направляется на цель, заранее объявленную оператором. Хосты вне области отклоняются.
  3. Исчерпание обходов перед отклонением ложного срабатывания: «заблокированная» нагрузка не означает отсутствия уязвимости, пока не опробован набор обходов.

⚠️ Жёсткие ограничения — прочитать перед каждым заданием​

Нарушение любого из них делает задание недействительным и может быть незаконным.

  1. Шлюз авторизации. Перед первым активным сканированием в сессии вы ОБЯЗАНЫ подтвердить с пользователем в письменном виде, что он владеет целью или имеет письменное разрешение на её тестирование. Зафиксируйте подтверждение в engagement/authorization.md (см. шаблон). Нет подтверждения → нет активного сканирования. Чтение публичных страниц через curl допустимо; отправка нагрузок — нет.

  2. Белый список области. Ведите engagement/scope.txt — одно имя хоста или CIDR на строку. Каждый запрос nmap, curl, whatweb, навигация браузера или запрос с нагрузкой ДОЛЖЕН быть направлен на запись из области. Если цель перенаправляет вас за пределы области (3xx на другой хост, ссылка в HTML), ОСТАНОВИТЕСЬ и подтвердите с пользователем, прежде чем переходить.

  3. Никаких продакшен-систем без документов. Если пользователь не сказал «да, продакшен в области, и у меня есть письменное разрешение», считайте, что нет. Цели по умолчанию — стейджинг, локальный docker, выделенные тестовые инстансы.

  4. Облачные метаданные по умолчанию запрещены. Не опрашивайте 169.254.169.254, metadata.google.internal, 100.100.100.200, [fd00:ec2::254] или аналоги, если только задание явно не включает SSRF-к-метаданным как цель И цель находится под вашим контролем. Инструмент браузера агента может достичь их из вашей собственной инфраструктуры — не делайте этого.

  5. Деструктивные нагрузки требуют одобрения. SQLi-нагрузки, выполняющие DROP/DELETE, SSTI с записью в файловую систему, внедрение команд с rm/shutdown/mkfs, любые изменения, выходящие за рамки одной тестовой строки → СПРОСИТЕ СНАЧАЛА. Система approval.py ловит некоторые из них; не полагайтесь только на неё.

  6. Риск утечки через вспомогательный клиент (специфично для VibeOS). Этот навык создаёт сессии, полные SQLi/XSS/RCE нагрузок, перехваченных учётных данных, JWT-токенов. Пути сжатия и генерации заголовков VibeOS воспроизводят историю через вспомогательный клиент (часто основную модель). Всё конфиденциальное, что вы записываете в разговор, может покинуть изолированную среду при следующем сжатии. Смягчение:

    • Сокращайте перехваченные токены/учётные данные до ПОСЛЕДНИХ 6 СИМВОЛОВ перед записью в любое сообщение. Полные значения сохраняются в файлы engagement/evidence/, никогда не попадают в историю чата.
    • Если задание чувствительное, установите auxiliary.title_generation.enabled: false в ~/.vibeos/config.yaml на время сессии.

  7. Ограничивайте скорость. По умолчанию 200 мс между активными запросами к любому одному хосту. Скрипт recon-scan.sh обеспечивает это. Не обходите его без одобрения оператора.

  8. Авторитет отчёта. Этот навык создаёт оценку безопасности, а не «ЗАЧЁТ». Даже чистый прогон — это «уязвимостей, поддающихся эксплуатации, НЕ ОБНАРУЖЕНО в области X за время T методами Y» — а не «приложение безопасно». Отражайте эту формулировку в отчёте.

Фаза 0: Настройка задания​

Перед любым сканированием создайте каталог задания и подтверждение авторизации.

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"

  1. Спросите пользователя (дословно):

    «Подтвердите: (a) целевой URL — [X], (b) вы владеете этим приложением или имеете письменное разрешение на его тестирование, и (c) задание может выполняться до [N] часов, начиная с сейчас. Ответьте «authorized», чтобы продолжить.»

  2. Дождитесь явного ответа authorized. Любой другой ответ означает СТОП.

  3. Запишите авторизацию в engagement/authorization.md, используя шаблон из templates/authorization.md. Включите:

    • Целевой URL(ы) и IP
    • Основание авторизации (владение / письменное разрешение от $имя)
    • Окно задания
    • Элементы вне области (продакшен, сторонние сервисы и т.д.)
    • Имя оператора (пользователь, управляющий этой сессией)

  4. Создайте scope.txt:

    localhost
    127.0.0.1
    staging.example.com
    192.168.1.0/24    # только внутренняя лаборатория, с одобрения оператора

  5. Прочитайте references/scope-enforcement.md перед отправкой первого активного запроса — в этом документе описаны правила извлечения хостов, которые вы применяете к каждой команде/URL перед отправкой.

Фаза 1: Предварительная разведка (анализ кода, опционально)​

Пропустите, если нет доступа к исходникам (тестирование «чёрного ящика»).

Если у вас есть доступ на чтение к исходному коду приложения:

  1. Составьте карту архитектуры — фреймворк, маршрутизация, стек промежуточного ПО
  2. Инвентаризируйте стоки — каждый execute(, os.system(, eval(, рендер шаблона, чтение/запись файлов, цель перенаправления
  3. Составьте карту аутентификации — сессионная cookie vs JWT, потоки OAuth, сброс пароля, привилегированные конечные точки
  4. Определите границы доверия — что аутентифицировано, что нет, что приходит из request.*
  5. Обратная трассировка от каждого стока к источнику запроса. Досрочно завершайте при обнаружении надлежащей санитизации (параметризованные запросы, белые списки, shlex.quote, известные экранировщики).

Результат: evidence/pre-recon.md — карта архитектуры, инвентарь стоков, предположительно уязвимые пути кода.

Это ОФЛАЙН-работа. Трафика к цели нет.

Фаза 2: Разведка (в реальном времени, только чтение)​

Составляет карту поверхности атаки. Все запросы — GET публичных страниц, нагрузок пока нет. По-прежнему ограничено областью.

  1. Проверьте область. Разрешите каждое целевое имя хоста → IP. Подтвердите, что IP находятся в области (избегает ловушки «DNS указывает куда-то не туда»).

  2. Сетевая поверхность (только если область разрешает сканирование портов):

    nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET

    Используйте -T3 (по умолчанию), не -T4/-T5. Более скрытно и избегает срабатывания IDS/IPS в общих средах.

  3. Технологический отпечаток:

    whatweb -v $TARGET_URL > evidence/whatweb.txt
    curl -sIk $TARGET_URL > evidence/headers.txt

  4. Обнаружение конечных точек:

    • Просканируйте приложение с помощью инструмента браузера (browser_navigate, browser_get_images, переходите по ссылкам).
    • Проверьте robots.txt, sitemap.xml, .well-known/*.
    • Используйте панель сети инструментов разработчика через инструмент браузера для захвата XHR/fetch-вызовов.

  5. Поверхность аутентификации: Определите вход, регистрацию, сброс пароля, имена сессионных cookie, форматы токенов. НЕ отправляйте учётные данные пока — только наблюдайте.

  6. Сопоставьте с предварительной разведкой (если есть исходники). Для каждого результата из evidence/pre-recon.md отметьте, подтверждает ли живая поверхность, что он достижим.

Результат: evidence/recon.md — конечные точки, технологии, модель аутентификации, векторы ввода.

Фаза 3: Анализ уязвимостей​

Один delegate_task на класс уязвимости. Каждый агент читает evidence/recon.md (+ evidence/pre-recon.md при наличии), создаёт findings/<class>-queue.json, используя templates/exploitation-queue.json.

Используйте delegate_task со следующими специализированными субагентами (параллельно, где возможно):

КлассЦельСправочник
injectionSQLi, внедрение команд, path traversal, SSTI, LFI/RFI, десериализацияreferences/vuln-taxonomy.md (типы слотов)
xssОтражённый, хранимый, DOM-basedreferences/vuln-taxonomy.md (контексты рендера)
authОбход входа, путаница JWT, фиксация сессии, ошибки OAuthreferences/exploitation-techniques.md
authzIDOR, вертикальная/горизонтальная эскалация, бизнес-логикаreferences/exploitation-techniques.md
ssrfВнутренняя достижимость, метаданные, протокольный смаглингПропустить метаданные, если явно не авторизовано
infraНеправильная конфигурация, раскрытие информации, учётные данные по умолчанию, открытая админкаreferences/exploitation-techniques.md

Каждая запись очереди содержит: id, класс уязвимости, источник (файл:строка, если известно), конечная точка, параметр, тип слота, предполагаемая защита, вердикт (identified / partial / confirmed / critical), подтверждающая нагрузка, уверенность (0-1), примечания.

Фаза анализа пока не отправляет вредоносные нагрузки — она их подготавливает. Фаза эксплуатации фактически их запускает.

Фаза 4: Эксплуатация (на основе доказательств, условно)​

Запускайте субагента только для тех классов, где очередь анализа содержит действенные записи (identified или partial).

Для каждого кандидата:

  1. Проверка перед отправкой — хост в области? шлюз авторизации пройден? нагрузка одобрена, если деструктивная?
  2. Отправьте подтверждающую нагрузку — минимальное доказательство. SQLi: ' AND 1=1-- затем ' AND 1=2--. XSS: безвредный маркер, например <svg/onload=console.log("VIBEOS-PENTEST-XSS")>. Никогда не используйте alert(1) в хранимом XSS — он сработает для других пользователей в общих средах.
  3. Проверьте, сработала ли подтверждающая нагрузка — для слепого внедрения используйте задержку (SLEEP(5)) и замерьте время ответа. Для SSRF используйте хост обратного вызова под вашим контролем (НЕ публичный сервис вроде webhook.site для чувствительных заданий — пути эксфильтрации).
  4. Повысьте уровень:
    • L1 Обнаружено — совпадение по шаблону, изменение поведения отсутствует
    • L2 Частично — сток достигнут, но защита активна
    • L3 Подтверждено — нагрузка изменила поведение приложения наблюдаемым образом
    • L4 Критично — данные извлечены, код выполнен, доступ повышен
  5. Исчерпание обходов перед классификацией как ЛП. Для каждого кандидата, который блокируется: попробуйте как минимум набор обходов из references/bypass-techniques.md для этого класса. Только после исчерпания набора вы можете записать verdict: false_positive.
  6. Запишите доказательства для каждого L3/L4:
    • Полный запрос (метод, URL, заголовки, тело)
    • Ответ (статус, заголовки, релевантный фрагмент тела)
    • Команда для воспроизведения (curl одной строкой)
    • Описание воздействия

Результат: findings/exploitation-evidence.md

Сокращайте в файлах доказательств:

  • Любые перехваченные учётные данные/токены → только последние 6 символов в чате; полное значение в findings/secrets-vault.md (в gitignore).
  • PII других пользователей → сократить.
  • Ваши тестовые учётные данные → можно оставить.

Фаза 5: Отчётность​

Создайте итоговый отчёт, используя templates/pentest-report.md. Разделы:

  1. Краткое резюме для руководства
  2. Область задания (из engagement/scope.txt)
  3. Авторизация (из engagement/authorization.md)
  4. Находки (только L3/L4 — требуется доказательство). Для каждой находки:
    • Название, критичность (CVSS 3.1), CWE
    • Затронутая конечная точка(и)
    • Доказательство (фрагмент запроса + ответа)
    • Шаги воспроизведения
    • Воздействие
    • Устранение
  5. Кандидаты, не эксплуатированные (L1/L2 с примечаниями о том, что их заблокировало)
  6. Наблюдения вне области
  7. Методология / использованные инструменты
  8. Ограничения и что НЕ тестировалось

Политика критичности: CVSS только для L3/L4. L1/L2 — «кандидаты, ожидающие проверки» — не присваивайте CVSS непроверенным находкам.

Когда остановиться​

  • Пользователь отзывает авторизацию.
  • Кандидатная находка явно затрагивает производственные данные, и у вас нет разрешения на деструктивное тестирование — ОСТАНОВИТЕСЬ и спросите.
  • Цель начинает возвращать 503/429 — отступите, свяжитесь с оператором.
  • Вы обнаруживаете что-то вне согласованной области (например, открытую базу данных клиентов при тестировании несвязанной конечной точки). ОСТАНОВИТЕСЬ, задокументируйте, сообщите оператору. Не переключайтесь без явного разрешения — именно такой переключатель делает пентест незаконным.

Что этот навык НЕ ПОКРЫВАЕТ​

  • Сетевой пентест за пределами сканирования портов (нет Metasploit, Cobalt Strike, AD-атак, фаззинга сетевых протоколов).
  • Обратная разработка / бинарный анализ (см. issue #383).
  • Статический анализ только исходников (см. issue #382).
  • Активная социальная инженерия / фишинг.
  • Любые действия против систем, которые оператор предварительно не авторизовал.

Если задание требует чего-либо из этого, обратитесь к профессиональному пентестеру. Этот навык дополняет профессиональный пентест; он не заменяет его.

Дополнительная литература​

  • references/scope-enforcement.md — как ограничивать каждый активный запрос
  • references/vuln-taxonomy.md — типы слотов, контексты рендера, карта OWASP
  • references/exploitation-techniques.md — шаблоны нагрузок по классам
  • references/bypass-techniques.md — распространённые обходы WAF/фильтров
  • templates/authorization.md — шаблон авторизации задания
  • templates/pentest-report.md — шаблон итогового отчёта
  • templates/exploitation-queue.json — схема очереди находок по классам
  • scripts/recon-scan.sh — обёртка с ограничением скорости для nmap+whatweb+headers