Статья Bug Bounty с нуля: от выбора программы до первого принятого репорта

Между регистрацией на платформе и первым принятым репортом у меня прошло четыре месяца, три дупликата и одно предупреждение за случайный выход за scope. За это время я отправил больше двадцати отчётов - приняли два. Один IDOR в API мобильного приложения финтех-сервиса, один reflected XSS в поддомене, который команда безопасности полгода не трогала. Суммарный баунти - чуть больше $200. Не миллион долларов, но именно эти два репорта показали: процесс работает, если подходить к нему как к методичной работе, а не к лотерее. Ниже я описал всё, что я хотел бы знать в момент регистрации.

Место Bug Bounty в цепочке наступательной безопасности​

Bug Bounty - не отдельная дисциплина. Это тот же пентест веб-приложений, но с открытым доступом, жёсткой конкуренцией и оплатой за результат. Багхантер симулирует поведение противника по MITRE ATT&CK. Его работа соответствует фазам разведки - Vulnerability Scanning (T1595.002), Gather Victim Host Information (T1592), Search Open Websites/Domains (T1593), Search Open Technical Databases (T1596 - запросы к Shodan, Censys, crt.sh, WHOIS) - и эксплуатации через Exploit Public-Facing Application (T1190, Initial Access).

[Применимо: внешний пентест, bug bounty]

Отличие от коммерческого пентеста принципиальное: нет гарантированной оплаты, нет фиксированного scope-документа от заказчика, нет NDA на методы. Зато есть конкуренция с тысячами других охотников, и побеждает тот, кто первым найдёт и грамотно оформит находку. Цепочка работы багхантера: выбор программы -> чтение scope -> разведка активов -> ручное тестирование -> обнаружение уязвимости -> написание репорта -> ожидание триажа. На каждом этапе - ловушки, в которые попадает большинство тех, кто пытается начать bug bounty с нуля.

Как выбрать первую программу Bug Bounty​

Самая частая ошибка - начать с Google, Apple или Meta. Программы IT-гигантов привлекают тысячи охотников с многолетним опытом. Вероятность найти что-то, что ещё не нашли, для начинающего стремится к нулю.

VDP или платная программа: decision tree​

Стратегия, которая реально работает для первых месяцев: VDP (Vulnerability Disclosure Programs). По наблюдениям исследователя RudraD (Hall of Fame NASA через Bugcrowd) и по данным сообщества StackExchange, VDP-программы дают конкретные преимущества для старта:

• Нет денежного вознаграждения - меньше конкуренция. Опытные охотники обходят VDP, потому что время - деньги. Новичку это развязывает руки.
• Hall of Fame всё ещё даёт репутацию, которая пригодится для приглашения в приватные программы с высокими выплатами.
• Ниже порог входа по сложности: компании с VDP часто имеют менее зрелую безопасность, чем те, кто платит $10 000 за критикал.

Параметры для оценки программы перед тем, как тратить время:

Критерий	Хороший знак для новичка	Плохой знак
Response time	Менее 7 дней до первого ответа	Более 30 дней, непрозрачный процесс
Средний bounty	Указан диапазон, есть статистика	"По усмотрению команды", нет данных
Ширина scope	Wildcard (*.target.com) с веб-приложениями	Один домен без API, статический сайт
Тип приложения	SaaS, финтех, e-commerce с API	Лендинг без функций
Активные охотники	Менее 100 за последний квартал	Тысячи конкурентов

Платформы bug bounty для начинающих: HackerOne (крупнейшая база программ, фильтрация по типу и сложности), Bugcrowd (система CrowdMatch подбирает программы под навыки, есть Bugcrowd University с вебинарами), Intigriti (европейская платформа с Fastlane Program для новичков, конкуренция ниже). В России работают Standoff Bug Bounty (Positive Technologies, выплаты до 10 млн рублей, программы VK, RuStore) и BI.ZONE Bug Bounty (программы банков и крупного бизнеса).

Отдельный приём для поиска менее конкурентных целей - Google Dorking. Запросы вида inurl:/security.txt, inurl:/responsible-disclosure, inurl:bug bounty reward находят программы, которые не размещены на крупных платформах и практически не охвачены другими охотниками. По опыту участников StackExchange, именно такие программы дают первые записи в Hall of Fame - конкуренции почти нет.

Scope Bug Bounty: как читать правила и не получить бан​

Scope - не просто список доменов. Это юридический документ, определяющий, что разрешено и что запрещено. Выход за scope в лучшем случае означает отклонение репорта, в худшем - бан на платформе или юридические последствия. В РФ несанкционированный доступ к компьютерной информации квалифицируется по статьям 272-274 УК. Не шутки.

Что проверять в scope bug bounty перед началом работы:

Разрешённые активы. Wildcard *.target.com означает все поддомены. Но часть поддоменов может быть явно исключена в разделе Out of Scope - читайте до конца. Отдельно могут быть перечислены API-эндпоинты, мобильные приложения, конкретные IP-диапазоны.

Запрещённые действия. Большинство программ запрещают: DoS/DDoS-тестирование, социальную инженерию сотрудников, физический доступ, автоматизированное сканирование без ограничения rate. Некоторые программы запрещают любой автоматизированный скан - и это критически важно знать до запуска nuclei или ffuf. Я на этом обжёгся.

Типы уязвимостей, которые не принимают. Типовой список отклоняемого: self-XSS (XSS, который срабатывает только для самого атакующего), отсутствие заголовков безопасности без демонстрации реального импакта, уязвимости в сторонних сервисах (CDN, аналитика, чат-виджеты), clickjacking на страницах без чувствительных действий.

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

Разведка цели: рабочий workflow для начинающих​

Требования к окружению​

• ОС: Kali Linux или любой GNU/Linux-дистрибутив (Ubuntu 22.04+). macOS с Homebrew тоже подходит.
• RAM: минимум 4 ГБ (8 ГБ рекомендуется при работе с большими списками субдоменов и параллельными запросами).
• Инструменты: Burp Suite Community или Pro, subfinder, httpx, ffuf (стек ProjectDiscovery, устанавливаются через go install). Python 3.8+ для вспомогательных скриптов.
• Сеть: стабильный интернет, VPN рекомендуется для ротации IP.
• Режим: только online, offline-работа для активной разведки невозможна.

Пассивная разведка и перечисление субдоменов​

Разведка - фаза, где формируется преимущество перед конкурентами. Бездумный запуск сканеров (Vulnerability Scanning, T1595.002) не даёт ничего - все делают то же самое. Работает многоисточниковый подход с ручной фильтрацией результатов.

Минимальный рабочий процесс перечисления субдоменов и проверки живых хостов:

subfinder -d target.com -o subs.txt
cat subs.txt | sort -u > unique_subs.txt
cat unique_subs.txt | httpx -silent -sc -title | tee alive.txt

На выходе - список живых поддоменов со статус-кодами и заголовками страниц. Дальше начинается ручная работа: просмотрите каждый поддомен. Старые интерфейсы, панели администрирования, забытые staging-среды - точки входа, на которые основная команда безопасности давно не смотрит. Именно там лежат находки для начинающих. На одном проекте я нашёл IDOR именно так - staging-версия API не имела проверки авторизации, которую давно прикрутили к production.

Отдельный приём, который выделяют исследователи из Intigriti: анализ JavaScript-файлов. JS-файлы часто содержат захардкоженные API-эндпоинты, токены, внутренние URL. Откройте DevTools -> Sources, ищите строки вида api_key, secret, internal, /api/v2/admin. Для автоматизации подойдёт linkfinder - она извлекает эндпоинты из JS-файлов и формирует список для дальнейшего тестирования.

Ещё один источник находок - мониторинг изменений. Согласно рекомендациям из гайда Intigriti по методологии, свежевыпущенные фичи приложения часто содержат уязвимости, потому что прошли минимальный security-review. Подпишитесь на changelog продукта, следите за обновлениями API-документации. Новый эндпоинт - первый кандидат на тестирование.

Ограничения автоматизированной разведки​

Автоматизация полезна для перечисления, но бесполезна для поиска уязвимостей бизнес-логики. Вот где она ломается:

• Rate limiting. Многие цели блокируют IP после нескольких сотен запросов в минуту. Запуск ffuf без флага -rate может привести к бану IP и нарушению правил программы.
• WAF. Cloudflare, Akamai, AWS WAF блокируют стандартные сканеры. nuclei с дефолтными темплейтами на защищённых целях выдаёт массу false positives.
• Дубликаты. Если уязвимость можно найти сканером - кто-то уже нашёл. Ценность для начинающих - в ручном тестировании бизнес-логики, которое автоматизации недоступно.

Первые находки Bug Bounty: какие уязвимости искать​

Не стоит начинать с RCE или SQL-инъекций. Не потому что они слишком сложные - а потому что вероятность найти их в зрелой программе для новичка минимальна. По данным OWASP Top 10 (2021), Broken Access Control (A01:2021) - первая позиция рейтинга, 34 категории CWE. Максимальный incidence rate доходил до 55.97%. Именно здесь лежат первые находки bug bounty для начинающих.

IDOR и Broken Access Control​

IDOR (Insecure Direct Object Reference) - подкласс Broken Access Control, который проще всего тестировать вручную. Суть: приложение позволяет получить доступ к объектам других пользователей, если подменить идентификатор в запросе.

[Применимо: внешний пентест, bug bounty, SaaS и e-commerce с пользовательскими данными]

Методика тестирования:

1. Создайте два тестовых аккаунта в целевом приложении.
2. Перехватите запрос к ресурсу (профиль, заказ, документ) через Burp Suite Proxy.
3. Подмените идентификатор объекта (числовой ID, UUID) на идентификатор из второго аккаунта.
4. Если сервер возвращает данные другого пользователя - это IDOR с реальным бизнес-импактом.

Где IDOR встречается чаще: API-эндпоинты мобильных приложений (часто менее защищены, чем веб), функции экспорта данных, endpoints управления настройками аккаунта, endpoints загрузки/удаления файлов. Мой первый принятый репорт был именно таким - мобильный API финтех-сервиса отдавал чужие транзакции при подмене order_id в GET-запросе. Проверка заняла минут двадцать.

Information Disclosure и Security Misconfiguration​

Security Misconfiguration (A05:2021, OWASP Top 10) - второй класс уязвимостей для старта. Точки проверки:

• Файлы .env, .git/config, web.config, phpinfo.php в корне и на поддоменах.
• Детальные сообщения об ошибках со stack traces, именами таблиц БД, внутренними путями файловой системы.
• Открытые директории (/backup/, /admin/, /debug/) - ffuf -w wordlist.txt -u https://target.com/FUZZ -mc 200,301,302 с секторными словарями.
• Заголовки ответа: X-Powered-By, Server с точными версиями, внутренние IP-адреса в нестандартных заголовках.

XSS - но не на первом шаге​

Cross-Site Scripting - самая популярная цель для новичков и одновременно самая конкурентная. На Security StackExchange прямо пишут: "большинство начинающих безумно тестируют XSS в любом месте на старте и бросают Bug Bounty после разочарования". XSS требует понимания контекста вывода (HTML-тело, атрибут тега, JavaScript-блок, URL-параметр) и техник обхода фильтрации. Если фильтры кодируют спецсимволы - стандартные пейлоады из шпаргалок не сработают.

Рекомендация: отрабатывайте XSS на лабораторных работах PortSwigger Web Security Academy (бесплатные, покрывают reflected, stored, DOM-based и mutation XSS), прежде чем тестировать на живых целях. Без понимания контекстов вывода шансы найти XSS, который ещё не нашли, близки к нулю.

Как написать репорт для Bug Bounty, который не отклонят​

Качество репорта определяет результат. Триажер тратит 3-5 минут на оценку - репорт должен быть структурирован так, чтобы за это время уязвимость можно было воспроизвести.

Структура принимаемого репорта (по данным гайда Netlas Bug Bounty 101):

1. Title. Одно предложение: [Тип уязвимости] в [компоненте] позволяет [действие]. Пример: "IDOR в /api/v2/orders/{id} позволяет получить данные заказов других пользователей".
2. Severity. Оценка по CVSS или собственной шкале программы. Не завышайте - триажер пересчитает, а завышение снижает доверие к репортёру. Я видел, как люди ставят Critical на reflected XSS без обхода CSP. Это сразу маркирует как новичка.
3. Description. Что за уязвимость, почему она опасна, какой бизнес-импакт. Не "я нашёл XSS", а "reflected XSS в параметре search позволяет выполнить произвольный JavaScript в контексте авторизованной сессии пользователя, что открывает возможность кражи cookie и захвата аккаунта".
4. Steps to Reproduce. Пронумерованные шаги, которые триажер выполнит без дополнительной информации. Каждый шаг - одно действие. Если нужна авторизация - укажите, какой тестовый аккаунт использовать.
5. Proof of Concept. Скриншоты, HTTP-запросы и ответы из Burp Suite, curl-команды для воспроизведения. Видео - если поток сложный. PoC должен быть минимально необходимым: один запрос, демонстрирующий уязвимость.
6. Impact. Что атакующий реально может сделать с этой уязвимостью. Триажер оценивает не факт наличия бага, а его последствия для бизнеса и пользователей.

Частые причины отклонения: дупликат (кто-то нашёл раньше), уязвимость вне scope, недостаточный импакт (self-XSS, missing headers без реального вектора атаки), невоспроизводимый PoC, нарушение правил программы.

Коммуникация с триажером: вежливо, лаконично, по делу. Если запрашивают дополнительную информацию - отвечайте в течение суток. Молчание дольше недели может привести к закрытию тикета.

Ошибки новичка Bug Bounty: шесть паттернов провала​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

6. Заброс после первых дупликатов. Дупликаты - нормальная часть процесса. На зрелых программах процент дупликатов для начинающего может быть очень высоким. Это не означает, что "всё найдено" - это означает, что низковисящие плоды собраны и нужно копать глубже: цепочки уязвимостей, edge-case сценарии, свежие фичи приложения, которые ещё не протестированы.

Поиск уязвимостей за вознаграждение - марафон, не спринт. Период от начала до стабильных находок занимает, по опыту сообщества, от нескольких месяцев до года при ежедневной практике. Программы с высокими выплатами становятся доступны после набора рейтинга через VDP и небольшие платные программы. В марте 2019 года HackerOne объявила Santiago Lopez первым багхантером, заработавшим $1 млн на платформе - но за этим стояли годы методичной работы. По данным годового отчёта Google Bug Hunters за 2023 год, суммарные выплаты составили порядка $10 млн - эти деньги распределились между сотнями активных исследователей с серьёзным опытом.

У меня есть убеждение, которое расходится с большинством "мотивационных" постов о Bug Bounty: основная причина провала - не нехватка технических навыков, а неготовность к монотонной работе. Разведка одного приложения неделями, чтение документации API, воспроизведение одного и того же потока авторизации с разными параметрами - это не захватывающий хакинг из фильмов. Это рутина с редкими моментами, когда сервер возвращает 200 вместо 403 и ты понимаешь, что нашёл что-то настоящее.

Кто к этому готов - собирает баунти. Остальные через три месяца пишут на форумах, что "Bug Bounty мёртв". Он не мёртв - изменился барьер входа. В 2018-2020 хватало запуска сканеров и базовых пейлоадов; в 2025 нужна методология, терпение и глубокое понимание одной цели. Начните с одной VDP-программы с широким scope и поставьте себе цель: один принятый репорт за 60 дней. Не десять. Один. Этого хватит, чтобы понять, ваш ли это формат работы - и выстроить процесс, который потом масштабируется.

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