Пентест и Bug Bounty: практический путь от основ до отчёта

Основы этичного хакинга, законность и правила Bug Bounty

Зачем начинать с этики и законности

Пентест и Bug Bounty выглядят похоже: вы ищете уязвимости. Разница в том, кто дал разрешение, в каких границах и по каким правилам вы работаете. В реальном мире эти рамки важнее любых техник.

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

Если разрешения нет или вы выходите за рамки — ваши действия могут стать:

Нарушением закона в вашей юрисдикции

Нарушением правил площадки (если вы в Bug Bounty)

Причиной ущерба бизнесу (простой, утечка, удаление данных)

Причиной блокировки аккаунтов и отказа в вознаграждении

Эта статья задаёт фундамент для всего курса: дальше мы будем изучать техники, но применять их будем только в легальных и безопасных сценариях.

Термины: пентест, Bug Bounty, VDP

Ниже — базовые понятия, без которых легко запутаться.

| Термин | Простое объяснение | Что обычно “на кону” | |---|---|---| | Пентест (penetration testing) | Проверка безопасности по договору, с согласованными целями и сроками | Контракт, отчёт, иногда повторная проверка (ретест) | | Bug Bounty | Публичная или полупубличная программа: вы находите баги по правилам, получаете вознаграждение за подтверждённые уязвимости | Репутация, выплаты, рейтинг на платформе | | VDP (Vulnerability Disclosure Program) | Программа раскрытия уязвимостей: можно сообщать о багах, но вознаграждения может не быть | Безопасный канал связи и правила раскрытия | | Scope (скоуп) | Точный список систем/доменов/приложений, которые разрешено тестировать | Легальность, возможность получить награду | | Out of scope | Явно запрещённые цели | Риск нарушить правила |

Полезные справочные источники:

OWASP Web Security Testing Guide

HackerOne Disclosure Guidelines

CISA Coordinated Vulnerability Disclosure

“Белые”, “серые” и “чёрные”: в чём реальная разница

Часто говорят про “white hat / gray hat / black hat”. Важно понимать это не как романтику, а как юридическую и этическую границу.

White hat: есть разрешение и понятные правила, действия укладываются в скоуп.

Gray hat: намерения могут быть “хорошими”, но разрешения нет или оно неоднозначно.

Black hat: цель — выгода через вред (кража, шантаж, саботаж), без согласия владельца.

Для карьеры в пентесте и Bug Bounty вам нужна позиция white hat: письменные правила, соблюдение скоупа, аккуратность и отчётность.

Базовые принципы этичного хакинга

Этичный подход можно свести к нескольким практическим принципам.

Разрешение важнее навыка: сначала право тестировать, потом сканеры.

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

Конфиденциальность: не распространять найденное и не публиковать детали до согласованного срока.

Повторяемость: шаги должны быть воспроизводимы, чтобы команда могла исправить.

Прозрачность: честно описывать, что вы делали, где и когда.

Часто безопасность описывают через триаду CIA (не про организацию, а про свойства информации):

Confidentiality (конфиденциальность): данные доступны только тем, кому положено.

Integrity (целостность): данные не меняются незаметно.

Availability (доступность): сервис работает, когда нужен.

Практический вывод для Bug Bounty: даже если вы нашли серьёзную проблему, нельзя “доказывать” её так, чтобы положить сервис (нарушить доступность) или массово выгрузить данные (нарушить конфиденциальность).

Законность: что делает тестирование легальным

Авторизация

Легальность почти всегда упирается в один вопрос: вам явно разрешили это делать?

Разрешение может быть оформлено как:

Договор на пентест (SOW/контракт)

Политика Bug Bounty на платформе (публичная оферта с правилами)

Политика VDP компании (правила раскрытия и разрешённые действия)

Если разрешение неявное (“мне кажется, что можно”) — это риск.

Скоуп и ограничения

Даже при наличии разрешения вы обязаны действовать внутри скоупа.

Скоуп обычно включает:

Домены, поддомены, приложения, API, мобильные приложения

Иногда диапазоны IP-адресов

Иногда конкретные аккаунты для тестирования

Ограничения обычно включают:

Запрет на DoS/DDoS и стресс-тесты

Запрет на социальную инженерию (фишинг, звонки, попытки получить пароли)

Запрет на физический доступ

Запрет на тестирование сторонних поставщиков (если не указано отдельно)

Юрисдикция и ответственность

Законы отличаются по странам, и один и тот же тест может трактоваться по-разному. В рамках курса мы не заменяем юриста, но придерживаемся безопасной практики:

Тестировать только там, где есть чёткое разрешение

Хранить доказательства и переписку (показывает добросовестность)

Избегать действий, которые выглядят как нанесение ущерба

Как устроен Bug Bounty на практике

Bug Bounty — это не “взломай что угодно”, а регламентированный процесс.

!Схема показывает типичный путь от чтения правил до выплаты и исправления

Типичный жизненный цикл:

Вы читаете политику программы и понимаете границы.

Вы тестируете только разрешённые цели и методами, которые не запрещены.

Вы находите уязвимость и подтверждаете её аккуратно.

Вы отправляете отчёт.

Команда триажа проверяет, задаёт вопросы, меняет статус.

При подтверждении — уязвимость исправляют, иногда платят награду.

Популярные платформы:

HackerOne

Bugcrowd

Intigriti

Правила Bug Bounty, которые нарушают чаще всего

Выход за пределы скоупа

Классические ошибки:

Тестировать “похожий” домен, который не указан в scope

Атаковать инфраструктуру поставщика (CDN, платёжку, сторонний SSO), если это не разрешено

Тестировать production-админки или внутренние панели, если они не в scope

Правило простое: если цели нет в списке — считайте, что нельзя.

Сбор лишних данных

Многие программы разрешают только минимальное доказательство.

Аккуратные примеры доказательства:

Показать, что доступ возможен, не выгружая всю базу

Замаскировать персональные данные в отчёте (редакция скриншотов)

Использовать тестовые аккаунты, если они предоставлены

Опасные примеры:

Массово выгружать данные “для убедительности”

Пытаться читать чужую почту/файлы, если уже ясно, что доступ есть

Публиковать PII (персональные данные) в отчёте без необходимости

Деструктивные действия

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

Часто запрещено:

DoS/DDoS и нагрузочные тесты

Удаление или порча данных

Изменение паролей/настроек чужих аккаунтов

Создание “шумных” массовых сканов, если политика это ограничивает

Safe Harbor: что это и почему важно

Safe harbor — это обещание компании не преследовать исследователя, если тот действует добросовестно и по правилам программы.

Но safe harbor почти всегда действует только при условиях:

Вы работаете в рамках scope

Вы соблюдаете запреты

Вы не пытаетесь вымогать деньги и не шантажируете

Вы сообщаете уязвимость через разрешённый канал

Полезный материал по теме:

HackerOne: Safe Harbor for Security Researchers

Если safe harbor не указан, это не означает “точно нельзя”, но означает повышенный риск и необходимость особенно внимательно читать правила и действовать осторожно.

Ответственное раскрытие (Coordinated Vulnerability Disclosure)

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

Важные идеи:

Сначала исправление, потом публичность

Согласованные сроки и коммуникация

Минимальный набор данных для воспроизведения

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

Официальный ресурс:

CVE Program

Практический чеклист перед началом тестирования

Используйте этот чеклист как обязательный “стартовый ритуал” перед любыми действиями.

Откройте политику программы и выпишите: scope, out of scope, запреты, правила отчёта.

Проверьте, что домен/приложение/диапазон IP точно совпадает с разрешённым.

Подготовьте отдельные аккаунты для тестов (не личные, если это возможно и не запрещено).

Решите, как вы будете фиксировать шаги: заметки, таймстемпы, скриншоты.

Сразу выберите “минимальный” способ доказательства, без лишних данных и без нагрузки.

Если что-то непонятно в правилах — задайте вопрос через официальный канал программы до активных действий.

Что дальше по курсу

Дальше мы перейдём к практической базе, без которой невозможно уверенно искать баги:

как работает HTTP/HTTPS и из чего состоят веб-запросы

как устроена аутентификация и сессии

какие классы уязвимостей встречаются чаще всего (OWASP Top 10)

как собирать доказательства и писать отчёт так, чтобы уязвимость быстро подтвердили

Эта статья — ваша “страховка”: любые техники имеют смысл только тогда, когда вы применяете их законно, безопасно и профессионально.

Сети и веб: фундамент для поиска уязвимостей

Зачем пентестеру понимать сети и веб

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

путать, где возникает проблема (клиент, сеть, сервер, приложение)

неверно интерпретировать симптомы (например, 403 не всегда значит “нет доступа”)

отправлять отчёты, которые невозможно воспроизвести

Эта статья — про фундамент: как данные ходят по сети и как устроено общение браузера с веб‑сервисом.

Карта уровней: где “живут” разные баги

Есть два популярных способа мыслить о сетевом стекe: OSI (7 уровней) и практическая модель TCP/IP (обычно 4–5 уровней). Для Bug Bounty важнее не запомнить “номера”, а понимать, на каком уровне вы наблюдаете эффект.

| Уровень (упрощённо) | Примеры технологий | Типичные симптомы | Примеры классов проблем | |---|---|---|---| | Сеть и транспорт | IP, TCP, UDP | таймауты, разрывы, нестабильность | ошибки конфигурации, неправильные ACL/фаерволы | | Прикладной протокол | DNS, HTTP, SMTP | неправильные ответы, редиректы, кэш | некорректные заголовки, утечки через ответы | | Приложение | логика сервиса | “чужие данные”, обходы ролей | IDOR, CSRF, XSS, SSRF, логические баги |

!Упрощённая карта слоёв от браузера до приложения

IP, порты и “куда вы вообще подключаетесь”

IP-адрес: “адрес дома” в сети

IPv4 выглядит как 203.0.113.10

IPv6 выглядит как 2001:db8::10

Важно: домен и IP — не одно и то же. Один домен может указывать на разные IP (балансировка), и один IP может обслуживать много доменов (виртуальный хостинг).

Порт: “дверь” конкретного сервиса

Порт — это число, которое помогает компьютеру понять, какому процессу передать входящее соединение.

HTTP часто работает на 80

HTTPS часто работает на 443

Практический смысл для тестирования: example.com и example.com:8443 могут быть разными сервисами с разными настройками.

NAT и фаервол

NAT часто “прячет” внутренние адреса за одним внешним.

Фаервол фильтрует трафик по правилам.

Для Bug Bounty это объясняет, почему сервис “виден” только из определённых сетей или почему часть портов закрыта.

TCP и UDP: как доставляются данные

TCP: надёжная доставка

TCP делает соединение “надёжным”: гарантирует порядок и доставку (или честно сообщает, что не получилось). В вебе (HTTP/1.1 и HTTP/2 поверх TCP) это встречается постоянно.

Ключевые понятия:

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

повторная отправка при потере пакетов

состояния соединения (у TCP они есть)

UDP: быстро, но без гарантий

UDP не устанавливает полноценное соединение и не гарантирует доставку. Он полезен там, где важнее скорость.

Примеры:

DNS часто использует UDP (хотя может и TCP)

некоторые realtime-протоколы

DNS: как имя превращается в адрес

DNS — это “телефонная книга” интернета: переводит доменные имена в технические записи.

Типы записей, которые чаще всего встречаются

| Запись | Для чего | Пример значения | |---|---|---| | A | домен → IPv4 | 203.0.113.10 | | AAAA | домен → IPv6 | 2001:db8::10 | | CNAME | псевдоним → другое имя | app.example.com → example.hosting.net | | MX | почтовые серверы домена | mx1.example.com | | TXT | текстовые политики | SPF/DMARC, верификации |

Почему это важно для поиска уязвимостей:

CNAME иногда показывает стороннего провайдера (и помогает понять границы scope и out of scope)

TXT‑записи могут содержать политики почты и интеграций

неправильная конфигурация DNS может приводить к проблемам доступности или захвату поддоменов (но проверять это нужно строго в рамках правил программы)

Полезные источники:

Cloudflare Learning: What is DNS?

RFC 1034: Domain Names — Concepts and Facilities

HTTP: язык веба

HTTP — это протокол запросов и ответов между клиентом (браузер, мобильное приложение, скрипт) и сервером.

Анатомия HTTP-запроса

Запрос состоит из:

метода (что сделать)

пути (какой ресурс)

заголовков (метаданные)

тела (данные, если нужно)

Пример (упрощённо, без “хакерских” действий):

Методы: что они обычно означают

GET: получить ресурс

POST: отправить данные (например, форма)

PUT/PATCH: обновить

DELETE: удалить

Важно: на практике разработчики иногда используют методы “не по учебнику”, и это влияет на тестирование логики и прав.

Ответ и статус-коды

| Код | Смысл | Как это интерпретировать | |---|---|---| | 200 | OK | запрос успешен | | 301/302 | Redirect | вас перенаправляют (важно: куда и почему) | | 400 | Bad Request | сервер не понял формат | | 401 | Unauthorized | нужна аутентификация | | 403 | Forbidden | доступ запрещён (но запрет может быть логический или ошибочный) | | 404 | Not Found | не найдено (иногда маскировка) | | 500 | Server Error | ошибка на стороне сервера (часто полезно для диагностики) |

Справочник:

MDN: HTTP response status codes

Заголовки, которые важны для безопасности

Host: помогает серверу понять, какой сайт вы запрашиваете на общем IP

Content-Type: как трактовать тело (JSON, form-data и т.д.)

Authorization: токены/ключи доступа (если используется)

Set-Cookie и Cookie: управление сессией

Origin и Referer: контекст запроса (важно для CSRF/CORS)

Справочник:

MDN: HTTP headers

Cookies и сессии: как сайт “помнит” вас

Cookie: маленький кусочек данных, который браузер отправляет обратно

Cookie — это данные, которые сервер может установить в браузер, а браузер будет прикреплять к последующим запросам на подходящие домены/пути.

Безопасные атрибуты cookie:

HttpOnly: cookie недоступна JavaScript в браузере (уменьшает риск кражи через XSS)

Secure: cookie отправляется только по HTTPS

SameSite: помогает снизить риск CSRF

Справочник:

MDN: Using HTTP cookies

Сессия: состояние на сервере или “токен” на клиенте

Есть два распространённых подхода:

server-side session: браузер хранит идентификатор (cookie), а состояние хранит сервер

token-based: браузер хранит токен (в cookie или другом хранилище), сервер проверяет подпись/валидность

Практический смысл для уязвимостей:

если идентификатор сессии можно угадать или украсть, это может привести к захвату аккаунта

неверные атрибуты cookie могут облегчать атаки на сессию

Same-Origin Policy и CORS: когда браузер “разрешает” запросы

Same-Origin Policy (SOP)

Браузеры ограничивают доступ скриптов к данным “чужого” источника.

Origin — это комбинация:

схема (http или https)

домен

порт

Пример: https://example.com и https://api.example.com — разные origin.

CORS

CORS — механизм, который позволяет серверу явно разрешить браузеру доступ с другого origin.

Важно понимать границы:

CORS — это защита браузера, а не “защита API вообще”

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

Справочник:

MDN: Same-origin policy

MDN: CORS

HTTPS и TLS: что реально даёт “замочек”

HTTPS = HTTP поверх TLS.

TLS обеспечивает:

конфиденциальность: трафик шифруется

целостность: сложнее незаметно изменить данные в пути

аутентичность сервера: сертификат подтверждает, что вы общаетесь с тем доменом

Что важно на практике:

“замочек” не гарантирует, что приложение безопасно: он защищает канал, а не бизнес-логику

ошибки в сертификатах, протоколах и настройках могут быть отдельным классом проблем

Справочник:

Cloudflare Learning: What is TLS?

!Как HTTPS “оборачивает” HTTP в TLS

Аутентификация и авторизация: не путать

Эти термины часто путают, но в отчётах их важно разделять.

Аутентификация: кто вы? (логин, пароль, 2FA, токен)

Авторизация: что вам можно? (роль, права на объект)

Очень много находок в Bug Bounty — это ошибки авторизации (например, доступ к чужому объекту), даже при “идеальной” аутентификации.

Наблюдаем трафик корректно: инструменты и артефакты для отчёта

В рамках правил программы (из первой статьи) вам нужно не “ломать”, а аккуратно наблюдать и фиксировать.

Что использовать

DevTools в браузере: вкладки Network/Storage для запросов, cookies, редиректов

Перехватывающий прокси (для своего трафика): помогает видеть и повторять запросы

Командные утилиты для диагностики: curl, dig, nslookup, traceroute

Сниффер трафика для обучения в лаборатории: Wireshark

Официальные источники:

Wireshark Documentation

curl documentation

Какие доказательства полезны в отчёте

точный URL, метод, важные заголовки (с редактированием секретов)

статус-код и ключевые фрагменты ответа

таймстемпы и условия (нужен ли логин, какая роль)

минимально необходимый скриншот или текстовый фрагмент

И важно из первой статьи: не собирать лишние данные и не выходить за scope.

Безопасная практика: где тренироваться

Чтобы набивать руку без риска нарушить законность и правила, используйте учебные стенды.

OWASP Juice Shop

DVWA (Damn Vulnerable Web Application)

Тренируясь, фокусируйтесь не на “магии эксплойта”, а на понимании: какой запрос ушёл, что вернулось, почему это небезопасно, и как это описать.

Что дальше по курсу

Теперь у вас есть базовые “координаты”:

как имя превращается в адрес (DNS)

как устанавливается связь (TCP/UDP)

как устроены запросы/ответы (HTTP)

как сайт держит состояние (cookies/сессии)

что делает HTTPS (TLS)

Дальше будем разбирать типовые классы веб‑уязвимостей и то, как подтверждать их минимально разрушительно и оформлять так, чтобы триаж быстро воспроизвёл проблему.

Разведка и картирование цели: recon и asset discovery

Зачем нужен recon в пентесте и Bug Bounty

Recon (разведка) — это этап, на котором вы находите и описываете поверхность атаки цели: какие домены, поддомены, приложения, API, внешние сервисы и точки входа реально существуют.

В контексте Bug Bounty recon решает две практические задачи:

Понять, что именно разрешено тестировать (и что запрещено).

Быстро находить “забытые” или менее защищённые компоненты (например, старые поддомены или экспериментальные API), не нарушая правил.

Recon напрямую опирается на две предыдущие статьи курса:

Из статьи про этику и законность: recon имеет смысл только в рамках scope и с учётом запретов (например, на агрессивные сканы и нагрузку).

Из статьи про сети и веб: вы используете понимание DNS, HTTP, TLS, cookies и принципов работы веба, чтобы корректно интерпретировать то, что находите.

Термины: recon, asset discovery, attack surface

Чтобы дальше говорить точно, зафиксируем базовые понятия.

Asset (актив): любой компонент, который принадлежит компании или обслуживает её пользователей (домен, поддомен, IP, веб-приложение, API, CDN-конфигурация, публичный бакет, репозиторий).

Asset discovery: процесс поиска таких активов из разрешённых источников.

Attack surface (поверхность атаки): все точки, через которые можно взаимодействовать с системой извне.

Passive recon (пассивная разведка): сбор данных без прямого “прикосновения” к инфраструктуре цели (поисковые системы, CT-логи, публичные репозитории).

Active recon (активная разведка): аккуратные запросы к активам (DNS-запросы, HTTP-запросы) для проверки, что актив существует и как он отвечает.

Границы: recon всегда начинается со scope

Recon чаще всего “ломается” не из-за техники, а из-за нарушения правил.

Перед любыми действиями выпишите в заметки:

In-scope: домены, поддомены, приложения, IP-диапазоны (если указаны).

Out-of-scope: явно запрещённые зоны (часто это сторонние провайдеры, корпоративная почта, физическая инфраструктура, социальная инженерия).

Запрещённые активности: DoS, стресс-тесты, агрессивные сканы, массовые брутфорсы.

Важно: даже если поддомен выглядит “очевидно принадлежащим компании”, он может указывать на сторонний сервис и быть out-of-scope. Это напрямую связано с темой DNS из предыдущей статьи: CNAME может вести на инфраструктуру провайдера.

Полезный ориентир по этапам тестирования и сбору информации:

OWASP Web Security Testing Guide (WSTG)

Практическая модель recon: от широкого к точному

Recon удобно вести как воронку: сначала вы собираете максимум сигналов пассивно, затем аккуратно подтверждаете активы запросами, затем строите понятную карту.

!Схема показывает последовательность recon от источников данных до приоритизации

Ключевая идея: на выходе recon у вас должен быть не “список всего”, а актуальный инвентарь активов, где отмечено, что действительно в scope.

Источники для asset discovery

Политика программы и документация

Самый недооценённый источник — сама программа:

Описание scope и примеры допустимых целей.

Ограничения по частоте запросов.

Указание тестовых аккаунтов и тестовых окружений.

В Bug Bounty это “истина”: если актив не указан и не подпадает под правила расширенного scope, считать его разрешённым нельзя.

DNS и связанные сигналы

Из статьи про сети и веб вы уже знаете, что DNS отвечает на вопрос куда указывает имя.

Что смотреть:

A и AAAA: куда резолвится домен (IPv4/IPv6).

CNAME: куда “переадресован” поддомен.

TXT: иногда содержит подсказки об используемых сервисах (почта, верификации).

Практическая цель DNS-recon в Bug Bounty:

Находить реальные рабочие имена.

Понимать, не указывает ли актив на третью сторону.

Инструменты диагностики (нейтральные и полезные в обучении):

Certificate Transparency (CT) и поддомены

Certificate Transparency — публичные журналы выпущенных TLS-сертификатов. Часто сертификаты содержат поддомены, которые не очевидны из главной страницы.

Полезный ресурс:

crt.sh

Интерпретация важна:

Наличие поддомена в CT-логах не гарантирует, что он сейчас жив.

Наличие имени не означает, что оно в scope.

Публичные репозитории и артефакты разработки

Часть поверхности атаки “утекает” через открытые репозитории и артефакты:

README, конфиги окружений, примеры запросов к API.

Ссылки на тестовые стенды.

Безопасная цель здесь — не “искать секреты любой ценой”, а понимать архитектуру и точки входа.

Ориентир по безопасной разработке и типовым местам утечек в приложениях:

OWASP Top 10

Веб-структура и навигационные подсказки

Даже без агрессивного краулинга вы можете извлечь полезные сигналы из браузера:

DevTools Network: какие хосты реально вызываются страницей.

Заголовки ответов: подсказки про прокси, CDN, тип сервера.

Редиректы: куда ведёт 301/302 и меняется ли домен.

Аккуратный способ “прощупать” актив без нагрузки — запросить только заголовки:

Валидация: как понять, что актив “живой” и что он из себя представляет

Recon ценен, когда вы умеете отличать “имя из списка” от реально работающего сервиса.

Минимальный набор вопросов при валидации:

Резолвится ли имя в IP (DNS)?

Отвечает ли HTTP(S), и какие коды статуса возвращает?

Есть ли редирект на другой домен (возможен уход на третью сторону)?

Похож ли ответ на приложение компании или на “заглушку” провайдера?

Важное замечание про статус-коды (из предыдущей статьи про HTTP):

403 часто означает “запрещено”, но иногда это фильтр по IP, WAF или неверная настройка.

404 иногда используется как маскировка (ресурс есть, но выдаётся “не найдено”).

Инвентарь активов: главный артефакт recon

Если вы участвуете в Bug Bounty, вам нужно уметь быстро ответить на вопросы:

Что именно вы тестировали?

Откуда вы это узнали?

Почему вы уверены, что это в scope?

Удобнее всего вести инвентарь как таблицу.

| Поле | Что записывать | Зачем это нужно | |---|---|---| | Актив | app.example.com, https://api.example.com | Однозначная идентификация цели | | Тип | веб, API, статик, панель админа, хранилище | Понимание класса рисков | | Источник | scope, CT, DNS, DevTools | Повторяемость и прозрачность | | In-scope? | да/нет/сомнительно | Защита от нарушений правил | | Наблюдения | редирект, WAF, требует логин | Приоритизация и контекст | | Дата проверки | когда вы видели это живым | Актуальность данных |

Если актив “сомнительный”, правильная стратегия — уточнить у программы через официальный канал до активных тестов.

Приоритизация: куда идти дальше, чтобы находить баги быстрее

Recon заканчивается не “списком”, а планом. Приоритизация — это выбор активов, где вероятность уязвимостей выше.

Типовые кандидаты с повышенным шансом находок:

Staging/dev/test окружения: часто хуже защищены и забыты.

Панели управления и внутренние интерфейсы, которые случайно доступны снаружи.

Старые версии API и “legacy” приложения.

Поддомены с разными стеками (признак разных команд и разного качества конфигураций).

Точки интеграций (SSO, webhooks, загрузки файлов), где часто встречаются логические ошибки.

Но приоритизация не отменяет правила: даже самый “вкусный” актив нельзя трогать, если он out-of-scope.

Ошибки recon, из-за которых теряют время и репутацию

Тестирование “похожих доменов”, не указанных в scope.

Игнорирование того, что CNAME может вести на сторонний сервис.

Слишком шумная активная разведка (частые запросы, брутфорс путей), которая нарушает ограничения программы.

Попытка “доказать” находку сбором лишних данных.

Отсутствие записей: без таймстемпов и источников ваши результаты трудно подтвердить.

Что должно остаться после recon перед поиском уязвимостей

К концу разведки у вас должны быть:

Инвентарь активов с отметками in-scope/out-of-scope.

Минимальные технические наблюдения по каждому активу (DNS, HTTP-коды, редиректы, наличие логина).

План приоритизации: 5–10 активов, которые вы проверите на типовые классы уязвимостей.

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

Тестирование веб-уязвимостей по OWASP Top 10

Зачем OWASP Top 10 в пентесте и Bug Bounty

После законности и правил (первая статья), сетево-веб фундамента (вторая) и разведки с инвентарём активов (третья) логичный следующий шаг — системно проверять веб‑приложения на самые частые классы рисков.

OWASP Top 10 — это список категорий рисков веб‑безопасности, которые чаще всего встречаются в реальных системах. Важно понимать границу:

OWASP Top 10 — не «чеклист всех багов», а карта самых распространённых причин компрометации.

Проверка по Top 10 становится эффективной, когда вы уже сделали recon и понимаете какие активы в scope, где логин, где API, какие роли.

Официальный источник:

OWASP Top 10 (2021)

Как превратить OWASP Top 10 в рабочий процесс

В Bug Bounty и пентесте выигрывает не тот, кто «запускает сканер», а тот, кто повторяемо проходит путь актив → гипотеза → минимальная проверка → доказательство → отчёт.

!Воронка: от инвентаря активов к проверкам OWASP и к отчёту

Минимальный набор подготовительных шагов

Убедитесь, что актив in-scope и вы не нарушаете запреты программы.

Подготовьте тестовые аккаунты и роли (если разрешено политикой).

Настройте наблюдение трафика: DevTools и перехватывающий прокси для своих запросов.

Ведите журнал: URL, роль, шаги, время, что изменили.

Полезный методический ориентир, как тестировать веб:

OWASP Web Security Testing Guide (WSTG)

Что считать «хорошим доказательством»

Один-два запроса, которые показывают проблему, без массового доступа к данным.

Скриншот или фрагмент ответа, где виден эффект (с редактированием секретов и персональных данных).

Чёткая привязка к роли и условиям: «неавторизован», «пользователь А», «пользователь B».

Быстрая карта OWASP Top 10 (2021)

Таблица ниже помогает связать категории риска с тем, что вы реально наблюдаете во время теста.

| Категория | О чём это | Частый «симптом» | Где часто находится | |---|---|---|---| | A01 Broken Access Control | неверные права доступа | доступ к чужим объектам | API, кабинеты, админки | | A02 Cryptographic Failures | проблемы шифрования и хранения секретов | утечки токенов, слабое хранение | логин, API, куки, бэкенд | | A03 Injection | ввод пользователя влияет на запросы/интерпретаторы | ошибки, «ломается» запрос | формы, фильтры, API | | A04 Insecure Design | опасная логика по задумке | нет ограничений в сценариях | бизнес-процессы | | A05 Security Misconfiguration | небезопасные настройки | лишние заголовки/эндпоинты | сервер, облако, фреймворк | | A06 Vulnerable and Outdated Components | уязвимые зависимости | старые версии, известные CVE | фронт, бэкенд, контейнеры | | A07 Identification and Authentication Failures | сбои входа и управления сессией | захват аккаунта/сессии | логин, 2FA, токены | | A08 Software and Data Integrity Failures | недоверенные обновления/данные | подмена артефактов | CI/CD, зависимости, вебхуки | | A09 Security Logging and Monitoring Failures | плохие логи и детектирование | атаки «не видны» | аутентификация, админка | | A10 SSRF | сервер делает запросы туда, куда не должен | доступ к внутренним ресурсам | интеграции, загрузки, превью |

Дальше — практический разбор каждой категории: что это, как аккуратно проверять и как описывать в отчёте.

A01 Broken Access Control

Контроль доступа — это правила, которые определяют, что конкретной роли можно делать с конкретным объектом. Ошибка здесь означает: «вы вошли как обычный пользователь, но можете действовать как другой пользователь или админ».

Типовые подвиды:

IDOR: доступ к чужому объекту по идентификатору.

Обход ограничений ролей: возможность вызывать админ‑методы.

Отсутствие проверки на уровне API: UI запрещает, API разрешает.

Аккуратные идеи проверки:

Найдите объектные идентификаторы в запросах (например, id, userId, orderId).

Проверьте, меняется ли объект при замене идентификатора на «соседний» или принадлежащий другому вашему тестовому аккаунту.

Для доказательства используйте минимальный объект и минимальный объём данных (например, имя/статус заказа, а не весь профиль).

Что писать в отчёте:

Какая роль и какой эндпоинт.

Какой объект удалось прочитать/изменить.

Почему это нарушение авторизации и какой impact (чтение, изменение, удаление).

A02 Cryptographic Failures

Криптографические сбои — это ситуации, когда конфиденциальные данные не защищены должным образом: плохое шифрование, неправильное хранение, утечки через транспорт или логи.

Что смотреть в веб‑контексте:

Есть ли HTTPS везде и нет ли «смешанного контента» на критичных страницах.

Атрибуты cookies для сессии: Secure, HttpOnly, разумный SameSite.

Не утекают ли токены в URL (query‑параметры), рефереры, логи, фронтенд‑хранилища.

Аккуратные идеи проверки:

В DevTools проверьте, как хранятся токены: cookie или localStorage; фиксируйте только факт и минимальный фрагмент (не публикуйте реальные токены).

Проверьте заголовки безопасности и параметры cookie в ответах.

Проверьте, не отдаёт ли приложение чувствительные данные там, где не должно (например, лишние поля в JSON-ответе).

Официальная справка по cookies:

MDN: Using HTTP cookies

A03 Injection

Инъекция — это класс проблем, где ввод пользователя попадает в интерпретатор (SQL, NoSQL, LDAP, шаблонизатор, командную строку) и меняет смысл операции.

Важно: в Bug Bounty подтверждение должно быть минимально разрушительным. Цель — показать управляемость интерпретации, а не «выкачать базу».

Сигналы, что стоит проверить инъекции:

Ошибки 500 или диагностические сообщения при необычном вводе.

Странные различия в ответах при кавычках/скобках/служебных символах.

Фильтры поиска, сортировки, отчёты, экспорты.

Аккуратные идеи проверки:

Найдите входы: параметры URL, поля форм, JSON‑поля в API.

Проверьте, есть ли валидация и нормальная обработка ошибок.

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

Учебные стенды для отработки инъекций:

OWASP Juice Shop

DVWA

Что писать в отчёте:

Точный параметр и контекст (где используется ввод).

Как меняется поведение приложения.

Почему это позволяет атакующему влиять на запросы/интерпретацию.

A04 Insecure Design

Небезопасный дизайн — это не «ошибка в конфиге», а опасное решение в логике продукта: даже при идеальной реализации оно открывает злоупотребления.

Примеры (на уровне идеи):

Нет лимитов на критичные операции (частота, сумма, попытки).

Нет проверки бизнес‑инвариантов (например, «оплата» возможна без «корзины»).

Опасные сценарии восстановления доступа или смены контактов.

Как тестировать:

Описывайте бизнес‑процесс как цепочку состояний.

Ищите шаги, которые можно пропустить, повторить, поменять местами.

Фиксируйте «что должно быть» и «что получилось».

Полезный ориентир по требованиям к безопасности приложений:

OWASP Application Security Verification Standard (ASVS)

A05 Security Misconfiguration

Ошибки конфигурации — это небезопасные настройки серверов, облака, фреймворков, заголовков и доступов.

Что часто встречается в реальности:

Отладочные режимы и подробные ошибки.

Открытые служебные панели.

Небезопасные CORS‑настройки.

Отсутствие базовых security headers.

Аккуратные идеи проверки:

Запросите только заголовки и посмотрите на поведение редиректов и CORS.

Ищите «служебные» пути, которые сами по себе не должны быть публичными, но не переходите к разрушительным действиям.

Справка по CORS:

MDN: CORS

A06 Vulnerable and Outdated Components

Уязвимые и устаревшие компоненты — это зависимости, фреймворки, контейнерные образы и библиотеки с известными уязвимостями.

Что можно делать безопасно в рамках веб‑тестирования:

Определять версии по публичным признакам (заголовки, файлы, сборочные артефакты), если это разрешено и не требует агрессивного сканирования.

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

Что важно для отчёта:

Версия компонента и источник, откуда версия получена.

Ссылка на публичное описание уязвимости (например, CVE или advisory).

Почему это применимо именно к этому активу.

Официальная база CVE:

CVE Program

A07 Identification and Authentication Failures

Это сбои в аутентификации (доказательство, кто вы) и управлении сессией.

Типовые проблемы:

Слабые механизмы восстановления аккаунта.

Отсутствие защиты от перебора паролей.

Сессионные cookie без HttpOnly/Secure.

Некорректная инвалидизация сессии (выход не завершает сессию).

Аккуратные идеи проверки:

Проверяйте «выход»: становится ли сессия невалидной.

Проверяйте политики паролей и 2FA без массового перебора.

Проверяйте, не остаются ли активные токены после смены пароля.

Что писать в отчёте:

Какой сценарий (логин, logout, reset password).

Какой результат и почему это риск (захват аккаунта, сохранение сессии).

A08 Software and Data Integrity Failures

Эта категория про ситуацию, когда система доверяет обновлениям, пакетам, данным или событиям, которые могут быть подменены.

В веб‑мире часто проявляется как:

Непроверенные зависимости и артефакты сборки.

Небезопасная обработка входящих событий (например, вебхуков), если нет проверки подлинности.

Аккуратные идеи проверки (без разрушения):

Убедиться, что входящие события/вебхуки имеют проверку подписи или секрет.

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

Официальная формулировка категории:

OWASP Top 10: Software and Data Integrity Failures

A09 Security Logging and Monitoring Failures

Категория про то, что атаки происходят, но:

не логируются критичные события,

логи не содержат нужного контекста,

нет мониторинга и реакции.

В Bug Bounty это часто сложно доказать «снаружи», но иногда возможно по косвенным признакам:

отсутствие уведомлений о входе с нового устройства,

отсутствие блокировок при подозрительных действиях,

предсказуемое отсутствие rate limiting в чувствительных местах.

Как корректно репортить:

Описывайте наблюдаемый эффект как риск, если нет прямого подтверждения внутренних логов.

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

Официальная формулировка категории:

OWASP Top 10: Security Logging and Monitoring Failures

A10 Server-Side Request Forgery (SSRF)

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

Где искать SSRF‑точки:

Импорт по URL.

Вебхуки.

Генерация превью по ссылке.

Интеграции, где «сервер сам скачает файл».

Аккуратные идеи проверки:

Найдите место, где вы задаёте URL.

Для подтверждения используйте контролируемый вами безопасный хост, который фиксирует факт обращения.

Не пытайтесь сканировать внутреннюю сеть и не делайте нагрузку.

Официальная формулировка категории:

OWASP Top 10: SSRF

Практическая связка с recon: как выбирать проверки под актив

Recon-инвентарь из предыдущей статьи удобно расширить до «карты проверок».

| Тип актива | На что сделать упор по OWASP Top 10 | |---|---| | Публичный веб без логина | A05, A06, часть A02 | | Кабинет пользователя | A01, A07, A02 | | API (особенно mobile/web) | A01, A03, A05, A07 | | Интеграции и вебхуки | A08, A10 | | Админ-панель | A01, A07, A09 |

Мини-шаблон заметок для будущего отчёта

Чтобы потом легко собрать отчёт, фиксируйте данные одинаково.

Актив и URL.

Scope-ссылка или цитата из политики (где указано, что актив разрешён).

Роль и учётка (обезличенно).

Шаги воспроизведения.

Ожидание и факт.

Минимальное доказательство (запрос/ответ, скрин).

Impact и рекомендация.

Что дальше по курсу

После того как вы научились мыслить категориями OWASP Top 10, следующий логичный шаг — углубиться в практику отчётности: как формулировать impact, как выбирать уровень детализации, как прикладывать доказательства так, чтобы триаж быстро подтвердил проблему, и как не нарушать правила программы при валидации уязвимости.

Аутентификация, сессии, IDOR и логические уязвимости

Как эта тема связывает весь курс

В прошлых материалах вы закрепили законность и рамки Bug Bounty, повторили базу HTTP/cookies/HTTPS, научились делать recon и системно смотреть на классы рисков по OWASP Top 10. Эта статья соединяет всё это в самый частый практический набор находок для новичка и для опытного охотника:

ошибки аутентификации и управления сессией (OWASP Top 10: A07)

ошибки контроля доступа и IDOR (OWASP Top 10: A01)

логические уязвимости и небезопасный дизайн (OWASP Top 10: A04)

Практическая цель: научиться отличать кто вы? от что вам можно?, понимать как приложение “помнит” пользователя, проверять это аккуратно и собирать доказательства так, чтобы триаж быстро воспроизвёл проблему.

Полезные ориентиры:

OWASP Web Security Testing Guide

OWASP ASVS

OWASP Top 10 (2021)

!Карта различий между аутентификацией, авторизацией и сессией

Термины, которые важно не путать

Аутентификация и авторизация

Аутентификация отвечает на вопрос кто вы? (логин/пароль, SSO, 2FA, токен).

Авторизация отвечает на вопрос что вам можно? (роль, доступ к конкретным объектам, правила бизнес-логики).

Частая ловушка в отчётах: исследователь пишет “broken authentication”, хотя проблема на самом деле в том, что обычный пользователь получает доступ к чужим объектам. Это почти всегда broken access control.

Сессия

Сессия — механизм, который связывает последовательность запросов с одним пользователем после входа.

Есть два распространённых подхода:

Сессионный идентификатор в cookie (состояние хранится на сервере).

Токен (например, JWT или другой формат), который клиент отправляет на каждый запрос.

База по cookie:

MDN: Using HTTP cookies

IDOR

IDOR (Insecure Direct Object Reference) — это частный случай ошибок контроля доступа: приложение принимает идентификатор объекта (например, orderId=123) и не проверяет, что объект принадлежит текущему пользователю или его роли.

Важно: IDOR почти всегда проявляется на уровне API или внутренних запросов фронтенда, даже если в интерфейсе всё выглядит корректно.

Логическая уязвимость

Логическая уязвимость — это способ злоупотребить функциональностью, когда:

система работает “как задумано”, но задумано небезопасно

или последовательность действий не защищена инвариантами (можно пропустить шаги, повторить действие, изменить параметры в неподходящий момент)

Это часто относится к A04 Insecure Design.

Как устроена типовая аутентификация в вебе

Что происходит при входе

На высоком уровне логин обычно выглядит так:

Клиент отправляет учётные данные на эндпоинт входа.

Сервер проверяет их и создаёт сессию.

Сервер возвращает “маркер” сессии.

Этот маркер часто выглядит как:

Set-Cookie: session=... в ответе

или Authorization: Bearer ... в последующих запросах

С точки зрения пентестера важны артефакты из статьи про HTTP:

заголовки Set-Cookie и атрибуты cookie

заголовок Authorization

поведение 302 редиректов после логина

Cookie и атрибуты безопасности

Если сессия хранится в cookie, проверяйте, что у сессионной cookie стоят разумные атрибуты:

Secure: cookie уходит только по HTTPS

HttpOnly: JavaScript не читает cookie, что снижает риск кражи при XSS

SameSite: снижает риск CSRF в браузерном контексте

Важно: отсутствие одного атрибута не всегда является “критичной” уязвимостью само по себе. В отчёте нужен контекст: какая cookie, какая роль, какие последствия.

Токены и где их хранят

Если используются токены, они могут храниться:

в cookie

в localStorage/sessionStorage

Практическая идея для Bug Bounty: фиксируйте факт хранения и последствия, но не публикуйте реальные токены.

Типовые сбои аутентификации и управления сессией

Ниже — проблемы, которые часто реально репортятся, и способы безопасно проверить их без разрушительных действий.

Некорректный logout

Симптом: пользователь нажал “выйти”, но старый маркер сессии продолжает работать.

Как проверять аккуратно:

Войдите в аккаунт и зафиксируйте запрос к защищённому ресурсу.

Выполните выход.

Повторите тот же запрос тем же маркером сессии и сравните поведение.

Что важно в отчёте:

какие шаги “выйти” выполняются

остаётся ли доступ к защищённым эндпоинтам

риск: захват аккаунта при компрометации токена

Сессии не инвалидируются при смене пароля

Симптом: после смены пароля старые активные сессии остаются валидными.

Как проверять:

Откройте сессию в одном браузере.

Во втором браузере смените пароль.

Проверьте, продолжает ли первая сессия работать.

Риск: атакующий, получивший доступ к сессии, “переживёт” смену пароля.

Слабые механики восстановления доступа

Симптомы, которые встречаются:

предсказуемые ссылки восстановления

отсутствие контроля попыток

возможность менять контактные данные без повторной проверки

Как тестировать безопасно:

используйте только свои тестовые аккаунты

избегайте массовых попыток, если политика программы ограничивает брутфорс

Ориентир по тестированию аутентификации:

OWASP WSTG: Authentication Testing

Broken Access Control и IDOR: самый частый “платёжный” класс багов

Модель “субъект → действие → объект”

Удобный способ мыслить про контроль доступа:

субъект: пользователь и его роль

действие: прочитать, изменить, удалить, выполнить

объект: конкретный ресурс, часто с идентификатором

IDOR почти всегда означает, что проверка связи субъект ↔ объект отсутствует или выполняется неверно.

Где искать идентификаторы объектов

Частые места, где “живут” object IDs:

параметры URL: ?id=..., ?orderId=...

сегменты пути: /users/123, /orders/123

поля JSON в API-запросах

скрытые поля формы

Подсказка из recon-статьи: часто удобнее начать с личного кабинета или API, где много объектных операций и понятные идентификаторы.

Аккуратный тест IDOR на своих аккаунтах

Безопасная последовательность проверки (если программа не запрещает мультиаккаунты):

Создайте два аккаунта: пользователь A и пользователь B.

Создайте объект у пользователя A (например, “заказ”, “черновик”, “адрес”).

Перехватите запрос, который читает или меняет объект пользователя A.

Выполните тот же запрос под пользователем B, подставив идентификатор объекта A.

Зафиксируйте минимальное доказательство: достаточно увидеть одно поле (например, статус или название), без выгрузки всех данных.

Что важно:

не перебирать идентификаторы массово

не использовать реальные чужие данные

не изменять объекты, если для доказательства достаточно чтения

!Как выглядит IDOR в запросах и ответах

Частые причины IDOR

проверка прав есть только в UI, но отсутствует на API

авторизация проверяет роль, но не проверяет владение объектом

объект доступен по “глобальному” идентификатору, а не по привязке к пользователю

кеширование или промежуточный сервис возвращает данные без дополнительной проверки

Как правильно формулировать impact в отчёте

Для триажа важна конкретика: что именно можно сделать, и чьи именно данные/объекты затрагиваются.

Хорошие формулировки:

“Пользователь B может читать профиль пользователя A, подставив userId в запросе”

“Пользователь B может изменять адрес доставки пользователя A через эндпоинт обновления”

Слабые формулировки:

“Можно получить доступ к чужим данным” без указания объекта и шага

Логические уязвимости: как их находить и доказывать

Логика обычно не “палится” ошибкой 500. Она проявляется тем, что вы можете сделать действие, которое бизнес не хотел позволять.

Модель состояний и инвариантов

Полезная техника: описать бизнес-процесс как состояния и правила.

Пример структуры:

Состояния: “корзина создана” → “оплата инициирована” → “оплата подтверждена” → “заказ завершён”.

Инварианты: что должно быть истинным в каждом состоянии.

Типовые логические проблемы:

пропуск шага: “подтвердить” можно без “оплатить”

повтор действия: бонус/скидка применяется несколько раз

гонка запросов: параллельные действия обходят лимит

несогласованность ролей: пользователь выполняет действие, которое должно быть только у сотрудника

Как тестировать логические уязвимости безопасно

Чтобы не нарушать правила Bug Bounty, действуйте как инженер качества:

Опишите ожидаемое поведение одним предложением.

Сделайте минимальный тест на своём аккаунте.

Зафиксируйте запросы и ответы, которые подтверждают нарушение.

Если затрагиваются деньги, баллы, подписки или реальные услуги, остановитесь на минимальном доказательстве и избегайте реального ущерба.

Если сомневаетесь, достаточно ли доказательства, лучше задать вопрос в программе до углубления.

Ориентир по “небезпечному дизайну”:

OWASP Top 10: Insecure Design

!Типовой паттерн логической уязвимости: обход шага процесса

Методика тестирования: от recon к воспроизводимому багу

Чтобы ваши проверки были быстрыми и “репортопригодными”, держите процесс одинаковым.

Мини-чеклист перед проверками

Актив точно in-scope.

Запрещённые действия не выполняются.

Есть тестовые учётки и роли, если это разрешено.

Включён сбор артефактов: DevTools Network или прокси для ваших запросов.

Что фиксировать, чтобы потом легко написать отчёт

точный URL, метод и параметры

какая роль и какое состояние сессии (вошёл/не вошёл)

ожидаемое поведение и фактическое поведение

минимальный фрагмент ответа, подтверждающий эффект

таймстемпы и окружение (prod/staging, если это указано в scope)

Частые ошибки новичков

Путать аутентификацию и авторизацию в формулировках.

Доказывать IDOR перебором идентификаторов, создавая лишний шум.

Собирать лишние персональные данные “для убедительности”.

Делать необратимые изменения (удаление, смена пароля) вместо безопасного чтения.

Не сохранять точные запросы и ответы, из-за чего триаж не может воспроизвести проблему.

Что дальше по курсу

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

проверка управления сессией и критичных сценариев входа

выявление IDOR и ошибок контроля доступа

поиск логических уязвимостей через модель процессов и инвариантов

Следующий логичный шаг — перейти к оформлению отчёта: как описывать шаги, impact и рекомендации так, чтобы баг быстро подтвердили и исправили, и при этом вы оставались в рамках правил программы.

Автоматизация и тулчейн: Burp Suite, сканеры, фазы triage

Зачем вам тулчейн, если уже есть OWASP Top 10 и recon

В прошлых статьях вы научились:

работать легально и в рамках scope

понимать базу HTTP/cookies/сессий

делать recon и собирать инвентарь активов

проверять типовые классы проблем по OWASP Top 10

находить и подтверждать ошибки аутентификации, сессий и IDOR

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

Тулчейн решает две задачи:

Наблюдаемость: вы точно видите, какие запросы уходят и что возвращается.

Повторяемость: вы можете воспроизвести шаги, минимально подтвердить impact и корректно пройти triage.

> Главная идея: автоматизация даёт покрытие, а Burp (или аналог) даёт точность и доказательства.

!Как инструменты связываются в единый процесс от recon до отчёта

Принципы безопасной автоматизации в Bug Bounty

Автоматизация чаще всего ломает карьеру не технически, а организационно: шум, нарушение правил программы, лишние данные.

Держите базовые правила (они продолжают идеи из первой статьи про законность и минимальный вред):

Scope-first: автоматизация запускается только по чётко размеченному списку in-scope активов.

Rate limit и вежливость: ограничивайте частоту запросов и параллелизм, особенно на production.

Минимальное доказательство: сканер может подсветить проблему, но подтверждение делайте аккуратно и точечно.

Логи и артефакты: сохраняйте входные списки, команды, версии шаблонов/правил, таймстемпы.

Разделяйте среду: по возможности используйте отдельный браузерный профиль и отдельные тестовые аккаунты.

Burp Suite как “центр управления” веб-тестированием

Burp Suite — стандартный инструмент для перехвата и ручного анализа HTTP(S)-трафика. Он особенно полезен для тех уязвимостей, которые сканеры находят плохо:

IDOR и ошибки авторизации

логические уязвимости

проблемы с сессиями

нестандартные инъекции, завязанные на бизнес-логике

Официальные источники:

Документация Burp Suite

Документация PortSwigger по веб-уязвимостям

Базовая настройка: чтобы не утонуть в трафике

Цель настройки — сделать так, чтобы вы видели только нужное и могли быстро повторять запросы.

Проект и сохранение состояния

1. Работайте в проекте Burp, чтобы сохранялась история, заметки и артефакты. 2. Фиксируйте, какой актив и какая роль тестируется (это потом почти дословно идёт в отчёт).

Scope в Burp

1. Добавьте домены/поддомены из вашего recon-инвентаря. 2. Настройте фильтры истории так, чтобы out-of-scope не отвлекал.

Перехват только когда нужно

1. Держите Intercept выключенным большую часть времени. 2. Включайте перехват точечно, когда нужно поймать конкретный запрос (например, изменение профиля или запрос к API).

Ключевые модули Burp и когда их применять

| Модуль | Что делает | Когда нужен в Bug Bounty | Типичный результат для отчёта | |---|---|---|---| | Proxy | перехват и история запросов | понять реальный API фронтенда, найти object IDs, токены, параметры | точный запрос/ответ + контекст | | Target / Site map | карта эндпоинтов по наблюдаемому трафику | быстро собрать attack surface конкретного приложения | список важных путей и API | | Repeater | ручное повторение и модификация запроса | IDOR, права, логика, валидации, заголовки | минимальный воспроизводимый PoC | | Intruder | автоматизация вариаций запросов | точечные проверки параметров, поиск обходов, слабые валидации | контролируемая серия запросов | | Scanner (в Pro) | пассивное/активное сканирование | быстрые “сигналы” по конфигам/инъекциям | список потенциальных мест | | Collaborator | внешний “маяк” для blind-классов | SSRF, blind XSS, некоторые XXE-подобные эффекты | доказательство обращения сервера | | Decoder / Comparer | декодирование и сравнение | JWT/URL/base64, сравнение ответов | наглядные различия | | Logger (через расширения) | удобное логирование и фильтрация | аккуратно собирать артефакты | чистая доказательная база |

#### Proxy: учимся видеть “настоящие” запросы приложения

Proxy — это место, где вы находите:

реальные API-эндпоинты, которые UI не показывает напрямую

идентификаторы объектов (id, orderId, сегменты /users/123)

заголовки и куки, которые определяют роль/сессию

Практический приём: начните с типовых действий, которые связаны с правами и объектами.

Просмотр профиля

Изменение email/адреса/настроек

Просмотр списка объектов (заказы, проекты, документы)

Просмотр конкретного объекта

Создание/изменение/удаление объекта на своём аккаунте

Это напрямую поддерживает тему из статьи про IDOR: вы быстро находите, где именно живёт object ID.

#### Repeater: главный инструмент подтверждения

Repeater превращает “подозрение” в воспроизводимый сценарий.

Типовые задачи:

проверить, что 403 действительно запрет, а не “маскировка”

заменить userId на идентификатор другого тестового аккаунта и подтвердить IDOR

проверить, какие поля реально принимаются бэкендом (например, “роль” или “статус”)

Мини-правило для отчёта: если вы можете показать проблему двумя запросами (A и B) — это идеальный формат для triage.

#### Intruder: автоматизация “малых серий”, а не брутфорс

Intruder полезен, когда нужно перебрать не пароли, а безопасные вариации:

несколько значений параметра, чтобы найти обход валидации

несколько форматов идентификатора (число/UUID/объект)

несколько заголовков или вариантов Content-Type

Важно для Bug Bounty: почти все программы запрещают агрессивный брутфорс. Поэтому Intruder используйте как точечный генератор тестов, соблюдая лимиты.

#### Scanner: как правильно использовать сигналы

Если у вас Burp Suite Professional, Scanner может дать хорошие подсказки по:

небезопасным заголовкам и конфигурациям

некоторым инъекциям

отражениям, которые могут быть XSS

Но сканер:

часто даёт ложные срабатывания

плохо понимает бизнес-логику

Правильная связка: Scanner → ручная проверка в Repeater → минимальное доказательство.

#### Collaborator: доказательства для “слепых” классов

Burp Collaborator помогает, когда эффект не виден в ответе приложения.

Примеры:

SSRF: сервер делает запрос на ваш контролируемый адрес

blind XSS: payload срабатывает в админке/логах

Этический акцент: подтверждайте только факт обращения и не используйте Collaborator для сканирования внутренних сетей или создания нагрузки, если это запрещено правилами программы.

#### Extensions: усиливаем Burp без самописной магии

Burp становится существенно удобнее с расширениями из магазина.

Официальный каталог:

BApp Store

Полезные классы расширений (названия могут отличаться, но смысл один):

логирование и удобные фильтры запросов

помощники по авторизации (поиск пропущенных проверок)

работа с токенами (например, JWT)

Альтернативы Burp и когда они уместны

Burp — не единственный вариант, и в некоторых сценариях удобнее другое.

OWASP ZAP: бесплатный прокси и сканер, хорош для базовой автоматизации и обучения

- Документация OWASP ZAP

mitmproxy: прокси, ориентированный на скриптование и автоматизацию

- Документация mitmproxy

Выбор практический:

если нужен мощный ручной анализ и быстрый Repeater-workflow, часто выбирают Burp

если важна бесплатность и “сканер из коробки”, часто выбирают ZAP

если вы хотите писать собственную логику перехвата, удобно смотреть в сторону mitmproxy

Сканеры и автоматизация: что именно автоматизировать

Автоматизация эффективна, когда задача:

повторяется

имеет чёткие входные данные

имеет понятные критерии “сигнала”

Ниже — типовая карта инструментов (как идея тулчейна, а не обязательный набор).

Инструменты для recon и валидации (поддержка вашего инвентаря)

поиск поддоменов и источников активов

- OWASP Amass - ProjectDiscovery subfinder

быстрая проверка “живых” HTTP(S) сервисов

- ProjectDiscovery httpx

сбор URL из публичных источников (аккуратно, только для in-scope)

- gau - waybackurls

Важно: эти инструменты легко “переехать” за границы scope, если вы кормите их неправильными списками. Поэтому сначала — таблица активов и фильтрация.

Инструменты для шаблонного сканирования

Шаблонные сканеры ищут известные паттерны уязвимостей и мисконфигов.

ProjectDiscovery Nuclei

Как применять в рамках Bug Bounty:

Кормите Nuclei только проверенными in-scope URL.

Ограничивайте скорость, параллелизм и количество запросов.

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

Инструменты для контент-дискавери и параметров

Иногда вам нужно найти скрытые пути или параметры, но делать это нужно осторожно.

фаззинг путей и файлов

- ffuf

поиск параметров (аккуратно, чтобы не создавать нагрузку)

- Arjun

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

Утилиты для воспроизводимости и обработки данных

curl для повторяемых запросов

- Документация curl

jq для чтения и сравнения JSON-ответов

- Руководство jq

Связка “Burp → curl” часто идеальна для отчёта: Burp помогает найти и отладить запрос, а curl — оформить минимальный воспроизводимый PoC.

Фазы triage: как превращать находку в принятый отчёт

Triage — это процесс подтверждения, классификации и обработки уязвимости. В Bug Bounty triage делают и вы (до отправки), и команда программы (после отправки).

!Жизненный цикл находки от сигнала до подтверждения и ретеста

Самостоятельный triage до отправки

Это этап, на котором вы экономите себе дни переписки.

Воспроизводимость

1. Убедитесь, что шаги повторяются минимум два раза. 2. Уберите случайные факторы: кэш, разные роли, разные окружения.

Минимальный PoC

1. Сведите доказательство к минимальному набору запросов. 2. Скрывайте секреты и персональные данные.

Классификация

1. Привяжите проблему к категории: например, A01 (Broken Access Control) для IDOR. 2. Не путайте аутентификацию и авторизацию (это частая причина отказа или неправильной тяжести).

Impact

1. Опишите, что может сделать атакующий: читать, менять, удалять, выполнять действие. 2. Объясните, почему это реально важно для бизнеса.

Проверка правил программы

1. Проверьте scope и ограничения: метод мог быть запрещён. 2. Если сомневаетесь — корректнее уточнить у программы, чем “дожимать”.

Triage со стороны программы: как это обычно выглядит

После отправки отчёта чаще всего происходят такие шаги:

Первичная проверка: есть ли воспроизведение по вашим шагам.

Проверка на дубликат: не репортил ли кто-то раньше.

Уточняющие вопросы: про роль, окружение, запросы, тайминг.

Оценка серьёзности: влияние, масштаб, практичность атаки.

Решение: accepted / informative / duplicate / out of scope / not applicable.

Чтобы пройти triage быстро, ваш отчёт должен содержать:

точный актив и подтверждение, что он in-scope

чёткую роль (неавторизован / пользователь / админ, если применимо)

шаги воспроизведения, которые не требуют догадок

конкретные запросы и ответы (с редактированием секретов)

ожидаемое поведение и фактическое поведение

impact и рекомендации

Практический тулчейн-воркфлоу: как это выглядит “день за днём”

Ниже — рабочий шаблон процесса, который связывает всё, что вы изучили в курсе.

Recon-инвентарь

1. Соберите активы. 2. Разметьте in-scope/out-of-scope. 3. Провалидируйте живые URL.

Быстрый baseline

1. Пробегитесь шаблонным сканером по списку URL (вежливо и в рамках правил). 2. Отметьте сигналы: странные заголовки, ошибки, доступные панели, подозрительные ответы.

Ручная проверка в Burp

1. Подтвердите сигнал через Proxy → Repeater. 2. Если это доступ/IDOR, используйте два тестовых аккаунта и минимальные данные.

Упаковка triage-готового доказательства

1. 2–6 шагов воспроизведения. 2. 1–2 ключевых запроса. 3. Скрин/фрагмент ответа с редактированием.

Отправка и коммуникация

1. Быстро отвечайте на уточнения. 2. При необходимости — повторите тест (ретест) и приложите новые артефакты.

Частые ошибки при автоматизации и работе с Burp

Пускать сканеры по “сырым” спискам доменов без фильтрации scope.

Пытаться доказать уязвимость “массовой выборкой данных”, вместо минимального PoC.

Принимать вывод сканера за факт без ручной проверки.

Не фиксировать роль, состояние сессии и точные запросы.

Делать слишком шумный контент-дискавери и получать блокировки (или нарушать правила программы).

Что дальше по курсу

Вы собрали связку:

правила и безопасные границы

сетевой и веб-фундамент

recon и инвентарь активов

системный подход OWASP Top 10

практику по сессиям, IDOR и логике

тулчейн для наблюдаемости, автоматизации и triage

Следующий шаг — финальная упаковка: как писать отчёт, который быстро подтверждают, правильно оценивают по impact и удобно чинят. Там мы соберём шаблон репорта, примеры хороших формулировок и типовые причины отказа triage.

Эксплуатация, доказательства, репортинг и коммуникация с программой

Зачем нужен этот этап

В предыдущих статьях курса вы научились работать легально и в рамках scope, разобрали фундамент веба, научились делать recon, смотреть на риски через OWASP Top 10, проверять сессии и IDOR, а также собрали практичный тулчейн (Burp, сканеры, triage).

Теперь ключевой шаг, который отделяет “я что-то нашёл” от accepted и выплаты:

аккуратно подтвердить уязвимость (эксплуатация как минимальная проверка, а не “взлом любой ценой”)

собрать доказательства, которые можно воспроизвести

упаковать это в отчёт, понятный triage и разработчикам

правильно общаться с программой, чтобы ускорить проверку и фиксацию

> В Bug Bounty ценится не максимальная “глубина взлома”, а минимально достаточное, воспроизводимое и безопасное доказательство, сделанное в рамках правил.

!Жизненный цикл находки: от сигнала до закрытия

Термины: эксплуатация, PoC, impact, triage

Чтобы не путаться в формулировках в отчётах и переписке, зафиксируем значения.

Эксплуатация: действия, которые показывают реальность уязвимости. В Bug Bounty это почти всегда означает минимальную демонстрацию (например, чтение одного поля вместо выгрузки таблицы).

PoC (Proof of Concept): доказательство концепции, то есть короткий воспроизводимый сценарий, подтверждающий проблему.

Impact: практический ущерб или риск для бизнеса и пользователей (что атакующий реально сможет сделать).

Triage: процесс проверки, классификации и принятия отчёта командой программы.

Полезный ориентир по тому, какие уязвимости бывают и как их объяснять:

PortSwigger Web Security Academy

Принципы безопасной “эксплуатации” в Bug Bounty

Эти принципы напрямую продолжают первую статью курса про законность и минимальный вред.

Минимально достаточное доказательство

Цель PoC — убедить, а не нанести ущерб. Выбирайте самый безопасный способ подтверждения.

Примеры хороших подходов:

показать доступ к одному объекту (одна запись, один документ), а не ко всем

показать, что действие возможно, но не доводить его до необратимого результата

использовать свои тестовые аккаунты и свои тестовые данные

Примеры плохих подходов:

массово выгружать данные ради “весомости”

менять настройки безопасности чужих аккаунтов

удалять данные или провоцировать простои

Воспроизводимость важнее “сложности”

Уязвимость без воспроизводимых шагов почти всегда заканчивается статусом Need more info или Not reproducible.

Мини-правило: если triage не может повторить ваш PoC за 10–15 минут, вы почти наверняка получите вопросы.

Политика программы важнее вашей уверенности

Перед углублением в подтверждение проверьте ограничения:

разрешены ли несколько аккаунтов

разрешены ли автоматизированные проверки

запрещены ли конкретные методы (например, агрессивный перебор, тесты доступности)

Ориентир по coordinated disclosure и безопасным рамкам:

HackerOne Disclosure Guidelines

Как собирать доказательства: что прикладывать и как не навредить

Что является сильным доказательством

Обычно лучший набор артефактов — это сочетание краткого текста и точных запросов.

Контекст

1. Актив (домен/приложение), подтверждение in-scope 2. Роль (неавторизован, пользователь, пользователь с ролью X) 3. Предусловия (нужна ли регистрация, нужен ли объект)

Шаги воспроизведения

1. Коротко, по действиям 2. Без “угадайте сами”, без пропусков

Ключевые HTTP-запросы

1. 1–2 запроса из Burp Repeater или curl 2. Важные заголовки и параметры

Ключевой фрагмент ответа

1. Минимальный фрагмент, который подтверждает эффект 2. С редактированием секретов и персональных данных

Редактирование: что скрывать

В отчёте нельзя “доказывать” уязвимость публикацией секретов. Перед отправкой:

удалите токены, пароли, ключи API

замаскируйте персональные данные (email, телефоны, адреса)

оставьте достаточно, чтобы triage видел различия (например, последние 2–4 символа)

Скриншоты и видео

Скриншот полезен как дополнительный слой, но он редко заменяет запросы.

хороший вариант: скриншот + запрос/ответ

слабый вариант: только скриншот “у меня получилось”

Как превращать “сигнал” в PoC: практический алгоритм

Этот алгоритм связывает вашу работу из статей про OWASP Top 10, IDOR и Burp.

Выберите гипотезу

1. Например: “это IDOR”, “это неправильная проверка роли”, “logout не инвалидирует сессию”

Сведите проверку к двум состояниям

1. “как должно быть” 2. “как получается у меня”

Сведите проверку к минимальному числу запросов

1. идеальный PoC: запрос A (норма) и запрос B (обход)

Проверьте воспроизводимость

1. повторите PoC минимум два раза 2. проверьте в чистом состоянии (новая сессия, новый браузерный профиль)

Проверьте границы воздействия

1. остановитесь на минимальном воздействии 2. не расширяйте доказательство до массового доступа к данным

Как писать отчёт, который быстро принимают

Что важно triage

Triage-процесс у разных программ отличается, но требования почти всегда одинаковые:

чёткий актив и подтверждение scope

конкретные шаги

конкретный impact

понятная классификация (например, A01 Broken Access Control для IDOR)

аккуратное доказательство без лишних данных

Ориентир по тестированию и структуре проверок:

OWASP Web Security Testing Guide

Структура отчёта (шаблон)

Ниже — практичная структура, которая подходит для большинства платформ.

Заголовок

1. Коротко: тип уязвимости + место + эффект 2. Пример: “IDOR в /api/orders/{id} позволяет читать чужие заказы”

Краткое описание

1. 2–4 предложения: что не так и почему это важно

Область воздействия

1. URL/эндпоинт 2. Роль/права 3. Условия (нужна ли авторизация)

Шаги воспроизведения

1. Нумерованный список действий 2. Отдельно: вариант A (ожидаемо) и вариант B (обход)

Фактический результат

1. Что происходит сейчас

Ожидаемый результат

1. Что должно происходить

Доказательства

1. запрос(ы) и ответ(ы) с редактированием 2. скриншот/видео при необходимости

Impact

1. что атакующий может делать 2. чьи данные/объекты затрагиваются

Рекомендации по исправлению

1. не “поставьте WAF”, а конкретная инженерная мера

Как писать impact, чтобы вас поняли

Impact должен отвечать на вопрос: какая реальная злоупотребляемость и что теряет бизнес.

Хорошие формулировки:

“Любой авторизованный пользователь может читать заказы других пользователей, подставив чужой orderId”

“После logout сессионный токен остаётся валидным и позволяет выполнять защищённые запросы”

Слабые формулировки:

“Можно взломать систему”

“Критическая уязвимость” без объяснения что именно можно сделать

Рекомендации: что писать вместо общих слов

Рекомендация должна быть применима к причине, а не только к симптому.

для IDOR: проверка владения объектом на сервере, привязка субъект ↔ объект на каждом доступе

для ошибок ролей: единая серверная авторизация, запрет на доверие к полям “role” с клиента

для сессий: инвалидизация токенов на logout и при смене пароля, короткая TTL для критичных токенов

Примеры “минимального PoC” на частых классах

Важно: примеры ниже описывают формат доказательства, а не “инструкцию взлома”. Применяйте только в разрешённых программах и на своих тестовых аккаунтах.

IDOR

Пользователь A создаёт объект и получает его id из запроса.

Пользователь B повторяет запрос чтения, подставив id пользователя A.

Доказательство: один фрагмент ответа (например, "status": "paid" или "title": "..."), без лишних данных.

Некорректный logout

Войти в аккаунт, открыть защищённый эндпоинт.

Выполнить logout.

Повторить запрос тем же маркером сессии.

Доказательство: сервер продолжает отдавать 200 и данные вместо 401/403.

Логическая уязвимость

Коротко описать ожидаемый бизнес-инвариант.

Показать, что последовательность шагов можно нарушить (пропуск, повтор, смена порядка).

Доказательство: изменение состояния или получение выгоды на тестовом аккаунте без реального ущерба.

Коммуникация с программой: как ускорить triage

Как отвечать на вопросы triage

В triage вас чаще всего попросит:

уточнить роль и условия

дать точные запросы

показать, что актив in-scope

подтвердить воспроизводимость

Стратегия ответа:

Ответьте по пунктам, в том же порядке, что вопросы.

Если вы добавляете новые артефакты, отмечайте что именно нового.

Если вы нашли ошибку в своём отчёте, прямо признайте и исправьте (это лучше, чем спорить).

Дубликаты, informative, “не уязвимость”

Возможные исходы и как действовать:

Duplicate: спросите, можно ли зачесть дополнительный impact или улучшенный PoC, но не спорьте без фактов.

Informative: уточните, какой критерий не дотянут (impact, воспроизводимость, политика программы).

Not applicable: перепроверьте, не тестировали ли вы out-of-scope, и не является ли это ожидаемым поведением.

Тайминг и ожидания

Не все программы отвечают быстро. Помогает аккуратная дисциплина:

держите у себя таймстемпы тестов

сохраняйте Burp-проект или curl-PoC

при долгом ожидании пишите короткий follow-up, но без давления

Severity и оценка риска: как не “перекрутить”

Площадки и компании могут использовать разные модели оценки: собственные матрицы, CVSS, внутренние правила.

Если вы упоминаете CVSS, делайте это аккуратно и как ориентир, а не как требование.

Официальный источник по CVSS:

FIRST CVSS v3.1 Specification

Практический совет: вместо “это 9.8” лучше написать:

какие роли нужны

насколько просто повторить

какой масштаб (один пользователь или все)

какие последствия (чтение, изменение, деньги, приватность)

Ретест и закрытие: как закрепить результат

Когда команда исправила уязвимость, вас могут попросить ретест.

Повторите исходный PoC в тех же условиях.

Зафиксируйте новый результат.

Если исправление частичное, покажите, что именно осталось возможным.

Если всё исправлено, подтвердите это и поблагодарите коротко и по делу.

Частые ошибки в отчётах, из-за которых теряют acceptance

нет подтверждения scope

нет роли и предусловий

шаги не повторяются или зависят от случайности

доказательство построено на лишних данных

перепутаны категории (аутентификация вместо авторизации и наоборот)

слишком длинный отчёт без структуры, triage не видит сути

Что вы должны уметь после этой статьи

отличать “сигнал” от подтверждённой уязвимости

делать минимальный PoC без вреда и без выхода за правила

собирать запросы/ответы как доказательную базу

писать отчёт, который быстро воспроизводится

вести коммуникацию с triage так, чтобы ускорять процесс, а не тормозить его

Эта статья завершает практическую дугу курса: от правил и фундамента — через recon и проверки — к корректной эксплуатации, доказательствам и профессиональному репортингу.