Bug Hunter: От первых шагов до профессионального Bug Bounty

ZYCT 10

Bug Hunter: От первых шагов до профессионального Bug Bounty

BUG HUNTER — От первых шагов до профессионального Bug Bounty

ZYCT

BUG HUNTER

От первых шагов до профессионального Bug Bounty

Автор: ZYCT

Об этой книге

Это практическое руководство по безопасности веб-приложений и Bug Bounty. Оно ведёт читателя от основ (сети, Linux, HTTP, устройство веб-приложений) к систематическому поиску уязвимостей в разрешённых целях, разработке собственных инструментов на Python и написанию профессиональных отчётов.

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

Лаборатория HunterMart, инструменты на Python и дополнительные файлы к книге доступны в репозитории: https://github.com/ZYCT10/BugHunterBook/

Как читать

Новичок: главы 1–5 подряд (основы, этика, HTTP, Linux/Python, разведка), затем классы уязвимостей (главы 6–11) по одному, с лабораториями.

Разработчик: главы 1–2, классы уязвимостей с разделами «Защитные меры» (главы 6–11), автоматизация на Python (глава 12).

Практикующий исследователь: разведка (глава 5), классы уязвимостей (главы 6–11), автоматизация (глава 12), триаж и отчётность (главы 13–14), лаборатории (глава 15) — как справочник и углубление.

Уровни сложности заданий обозначены от 1 (понимание терминов) до 8 (профессиональный отчёт).

Правовые и этические рамки

Любое практическое действие выполняется только: в локальной лаборатории, в специально предназначенной учебной среде, на собственных системах либо в пределах явно разрешённого scope программы. Перед началом работы пройдите «Чек-лист безопасного тестирования» (приложение). Ответственность за применение знаний несёт читатель.

Глава 1. Введение в Bug Bounty

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

Предварительные требования. Базовое умение пользоваться компьютером. Специальных знаний по безопасности не требуется.

Результаты обучения. После главы вы сможете: (1) объяснить, чем Bug Bounty отличается от пентеста, red team, VDP и vulnerability research; (2) описать полный жизненный цикл находки — от выбора программы до выплаты; (3) трезво оценивать экономику и трудности этого занятия; (4) понимать, какое место занимает исследователь в экосистеме безопасности.

1.1. Что такое Bug Bounty

Bug Bounty (программа вознаграждения за уязвимости) — это публичное приглашение владельца системы: «найдите у нас уязвимости по этим правилам, сообщите нам, и мы заплатим за подтверждённые находки». Исследователь (bug hunter, или researcher) ищет уязвимости в разрешённых целях, оформляет отчёт, а владелец — как правило, через команду триажа (triage) — проверяет находку, оценивает её и выплачивает вознаграждение (bounty).

Ключевое слово — разрешение. Bug Bounty легален именно потому, что владелец заранее и публично разрешил тестирование в оговорённых границах. То же действие без разрешения — правонарушение. Мы возвращаемся к границам, scope и «тихой гавани» в главе 2; здесь важно зафиксировать принцип: нет разрешения — нет исследования.

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

Воспринимайте Bug Bounty не как «взлом за деньги», а как возмездный аудит по правилам. Эта рамка убережёт и от юридических проблем, и от выгорания: вы не воюете с системой, вы помогаете закрыть в ней дыры и получаете за это вознаграждение.

1.2. Место исследователя в экосистеме безопасности

Чтобы понять, где находится bug hunter, разведём несколько ролей и дисциплин. Они часто пересекаются, но образ мышления и рамки у них разные.

Оборонительная безопасность (Defensive Security, «blue team»). Построение и эксплуатация защиты: безопасная разработка, мониторинг, обнаружение и реагирование на инциденты. Их метрика — устойчивость.

Наступательная безопасность (Offensive Security, «red team»). Моделирование действий реального противника, чтобы найти слабые места раньше него. Метрика — насколько глубоко удалось продвинуться.

Безопасность приложений (Application Security, AppSec). Дисциплина на стыке разработки и безопасности: моделирование угроз, ревью кода, тестирование, исправления на уровне конкретного приложения. Многие исследователи приходят в Bug Bounty из AppSec и наоборот.

Bug hunter. Работает на стыке offensive и AppSec, но всегда в легальных рамках программы. Находит, подтверждает, документирует и помогает исправить.

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

1.3. Bug Bounty, VDP, пентест, red team, vulnerability research

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

Несколько важных различий подробнее.

Bug Bounty против пентеста. Пентест ограничен временем и людьми: нанятая команда за, скажем, две недели проходит оговорённый периметр и сдаёт отчёт. Bug Bounty — непрерывный процесс с неограниченным числом исследователей, которые смотрят на систему годами и под разными углами. Пентест даёт полноту за фиксированную цену; Bug Bounty даёт «длинный хвост» нестандартных находок и платит только за результат.

Bug Bounty против red team. Red team проверяет не только систему, но и способность организации заметить и остановить атаку; это скрытная операция с имитацией конкретного противника. В Bug Bounty скрытность не нужна — наоборот, вы действуете открыто и по правилам.

VDP (Vulnerability Disclosure Program). Это «дверь» для сообщений: «если вы что-то нашли, сообщите сюда безопасно, и мы не станем вас преследовать». Часто без денег. Bug Bounty можно считать VDP с вознаграждением. Понятие safe harbor («тихая гавань») — раздел политики, где владелец обязуется не инициировать преследование добросовестного исследователя, действующего в рамках правил. Его читают дословно (глава 2).

Vulnerability research. Поиск ранее неизвестных уязвимостей или целых их классов — часто в продуктах, библиотеках, протоколах. Результат может оформляться как CVE (Common Vulnerabilities and Exposures) — запись в публичном каталоге уязвимостей. Это соседняя дисциплина; многие приёмы общие.

1.4. Как на самом деле выглядит работа

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

Это не «запустил сканер — получил деньги». Автоматические сканеры находят шум: тысячи «потенциальных» проблем, из которых подавляющее большинство — ложные срабатывания или находки нулевой ценности. Настоящая работа — это проверка гипотез о логике приложения, а её сканер не делает. Мы посвящаем мышлению исследователя главу 5 и возвращаемся к нему в каждой главе части про уязвимости.

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

Много ложных срабатываний. Значительная часть времени уходит на то, чтобы отсеять то, что лишь выглядит уязвимостью. Умение уверенно сказать «это не баг» — профессиональный навык, а не признак слабости. Мы выделяем ложные срабатывания отдельными врезками в каждой главе.

Доход негарантирован и неравномерен. Эта книга не обещает заработок и не приводит «средних цифр дохода» — они вводят в заблуждение, потому что распределение выплат крайне неравномерно: небольшая доля исследователей получает большую часть вознаграждений. Правильнее думать о Bug Bounty как о способе развить навык, который монетизируется по-разному: собственно выплаты, работа в AppSec, пентест, исследования, преподавание.

Обучение не заканчивается. Технологии, фреймворки и защиты меняются. Приём, работавший вчера, сегодня закрыт новой версией библиотеки. Устойчивый результат даёт не коллекция «трюков», а понимание механизмов — поэтому книга построена вокруг причин уязвимостей, а не рецептов.

Между «обнаружил уязвимость» и «получил вознаграждение» лежит большая дистанция: подтверждение, оценка влияния, качественный отчёт, триаж, возможный дубликат и решение программы. Главы 13 и 14 целиком посвящены этому «последнему километру».

1.4.1. Как выглядит типичная сессия исследования

Чтобы заземлить ожидания, опишем обобщённый ход одной сессии (без романтики):

Выбор и подготовка (15–30 мин). Открыть программу, перечитать scope и правила, поднять заметки и инструменты, проверить, что цель в границах.

Разведка и карта (часто дольше всего). Пройтись по функциям, собрать эндпоинты, роли, точки ввода (глава 5). Здесь рождаются гипотезы.

Проверка гипотез. Аккуратные эксперименты: «что если запросить чужой id?», «что если поле роли примут?». Большинство гипотез не подтверждается — это норма.

Отсев шума. Отличить реальную находку от ложного срабатывания (контрпроверка, глава 13). Часть времени уходит именно сюда.

Оформление. Для подтверждённой находки — минимальный PoC, доказательства, отчёт (главы 13–14).

Обратите внимание на пропорции: собственно «эксплуатация» — малая часть; больше всего времени занимают разведка, проверка гипотез и отсев шума. Это не «взлом за минуту», а методичная работа. Понимание этого отличает тех, кто остаётся в профессии, от тех, кто бросает после первых недель без мгновенного результата.

1.5. Жизненный цикл находки

Чтобы увидеть процесс целиком, пройдём его по шагам. Это каркас, который мы детализируем в главах 5, 13 и 14; здесь — обзорная карта.

Выбор программы. Оценка границ, технологий, активности, конкуренции (раздел 1.6 и глава 2).

Чтение правил и scope. Что разрешено, что запрещено, что вне границ, какова safe harbor.

Картирование поверхности атаки. Домены, приложения, API, роли, точки ввода (глава 5).

Разведка. Пассивная и активная, строго в пределах scope (глава 5).

Формирование гипотез. «Что здесь может пойти не так и почему» — на основе наблюдаемого поведения.

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

Исключение ложных срабатываний. Отделить реальную уязвимость от шума и реакций фильтров.

Оценка влияния и серьёзности. Какой актив затронут, каковы последствия (глава 13; CVSS — глава 14).

Подготовка доказательств (PoC). Минимально достаточная демонстрация (глава 13).

Написание отчёта. Воспроизводимо, честно, по структуре (глава 14).

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

Повторная проверка исправления. Если программа это предусматривает.

Разбор результата. Что сработало, что нет, чему научились — развитие навыка.

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

Жизненный цикл находки в Bug Bounty

1.6. Выбор программы: первая развилка

Выбор программы сильнее влияет на результат, чем техника. Несколько ориентиров (подробно — глава 2 и 5):

Широта scope. Чем больше разрешённых активов (домены, поддомены, API, мобильные приложения), тем больше неисследованной поверхности. Широкий scope часто продуктивнее «одной страницы входа».

Зрелость программы. Давно работающие программы крупных компаний отполированы тысячами исследователей — там выше конкуренция и больше дубликатов. Молодые программы рискованнее по выплатам, но менее «вытоптаны».

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

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

«Большой бренд = лёгкие деньги» — опасное заблуждение. Чем известнее цель, тем плотнее её уже изучили. Иногда разумнее менее раскрученная программа с широким scope и адекватным триажем.

1.6.1. Экономика находок: честная картина

Распределение вознаграждений в Bug Bounty сильно неравномерно — это важно понимать, чтобы не строить нереалистичных ожиданий. Несколько устойчивых закономерностей (без конкретных цифр, которые быстро устаревают и разнятся между платформами):

Выплаты зависят от серьёзности и влияния, а не от объёма усилий. Один отчёт об уязвимости высокой серьёзности часто стоит больше, чем десятки «информационных» находок.

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

Время до первого результата может быть долгим. Освоение целей и методологии занимает недели и месяцы; доход на старте непредсказуем и часто близок к нулю.

Навык переносим. Умение находить и описывать уязвимости ценится в AppSec, пентесте, исследованиях и преподавании — это снижает зависимость от конкретных выплат.

Практический вывод: относитесь к Bug Bounty как к инвестиции в навык с отложенной и неравномерной отдачей, а не как к источнику стабильного дохода. Эта книга не обещает заработка и намеренно не приводит «средних доходов» — такие цифры вводят в заблуждение из-за перекошенного распределения.

1.6.2. Платформы и прямые программы

Программы существуют в двух формах: на платформах-посредниках (которые агрегируют программы, ведут триаж и выплаты) и как прямые программы компаний (собственная страница безопасности, свой канал приёма). Для начинающего платформы удобнее: единый интерфейс, история репутации, стандартизированный процесс. Прямые программы бывают менее «вытоптаны», но требуют больше самостоятельности. В любом случае правила, scope и safe harbor читаются по конкретной программе (глава 2) — не переносите условия одной платформы на другую.

1.7. Этика и легальность как фундамент

Мы подробно разбираем это в главе 2, но принцип вводим сразу, потому что он не опционален.

Исследование безопасности легально при одном из условий: (1) это ваша собственная система; (2) это специально предназначенная учебная среда или локальная лаборатория (как HunterMart в этой книге); (3) вы действуете в пределах явно разрешённого scope программы и по её правилам. Во всех остальных случаях — нельзя, какими бы благими ни были намерения.

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

Доступность системы из интернета — не разрешение её тестировать. «Я же только посмотрел» — не оправдание. Разрешение даёт либо владелец (в scope программы), либо тот факт, что система ваша или локальная.

1.8. Как пользоваться этой книгой

Маршрут новичка. Главы 1–5 подряд (основы, этика, HTTP, инструменты, разведка), затем классы уязвимостей (6–11) по одному, обязательно с лабораториями HunterMart, затем триаж и отчётность (13–14).

Маршрут разработчика. Главы 1, 3, разделы «Защитные меры» в главах 6–11, затем 14. Цель — понять, как думает атакующий, чтобы писать устойчивый код.

Маршрут практикующего исследователя. Главы 5, 6–11 как углубление, 12 (автоматизация), 13–14 как рабочий справочник.

Уровни сложности заданий обозначены от 1 (понимание терминов) до 8 (профессиональный отчёт). Решения практикумов вынесены в отдельную часть (глава 15), чтобы вы могли сначала попробовать сами.

1.8a. Задания (уровни 1–3)

Уровень 1. Своими словами объясните, что такое Bug Bounty и чем он отличается от «взлома».

Уровень 1. Составьте таблицу различий Bug Bounty / VDP / пентест / red team по инициатору, границам, оплате и цели.

Уровень 2. Опишите полный жизненный цикл находки (13 шагов) и отметьте, какие шаги возвращают назад.

Уровень 3. Выберите (как учебное чтение) публичную программу и оцените её по критериям раздела 1.6 (ширина scope, зрелость, технологии, отзывчивость). Обоснуйте, подошла бы она новичку.

1.9. Резюме

Bug Bounty — это возмездный аудит по правилам: владелец публично разрешает искать у него уязвимости и платит за подтверждённые находки. Исследователь работает на стыке offensive и AppSec, всегда в легальных рамках. Форматы (Bug Bounty, VDP, пентест, red team, research) различаются инициатором, границами, оплатой и целью. Реальная работа — это проверка гипотез, борьба с ложными срабатываниями и дубликатами, неравномерный доход и непрерывное обучение; поэтому книга делает ставку на понимание механизмов. Полный цикл находки — от выбора программы до проверки исправления — задаёт структуру всей книги.

1.10. Контрольные вопросы

Чем Bug Bounty отличается от пентеста по модели работы и оплаты? А от red team — по цели?

Что такое VDP и safe harbor и почему последнее читают дословно?

Почему «запустить сканер» — не стратегия поиска уязвимостей?

Что такое дубликат и почему он не означает, что находка была невалидной?

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

Перечислите шаги жизненного цикла находки и объясните, почему это цикл, а не прямая линия.

1.11. Источники

OWASP, общие материалы о Bug Bounty и раскрытии уязвимостей — https://owasp.org/www-community/Vulnerability_Disclosure_Cheat_Sheet (проверено 2026-10-19).

disclose.io — шаблоны политик и safe harbor (справочно) — https://disclose.io/ (проверено 2026-10-19).

CVE Program — https://www.cve.org/ (проверено 2026-10-19).

OWASP Top 10:2025 (контекст классов уязвимостей) — https://owasp.org/Top10/2025/0x00_2025-Introduction/ (проверено 2026-10-19; часть материалов какое-то время публиковалась в статусе preview — сверяйте финальные формулировки по owasp.org).

Глава 2. Правила программ, границы и этика

Цель главы. Научиться читать правила Bug Bounty так, чтобы не выйти за границы закона и программы, понимать scope и safe harbor, вести исследование безопасно и этично, и правильно обращаться с найденными данными. Это не «юридический довесок», а операционная основа профессии.

Предварительные требования. Глава 1.

Результаты обучения. Вы сможете: (1) разобрать политику программы и выделить разрешённое, запрещённое и вне-scope; (2) объяснить safe harbor и его пределы; (3) провести тест, не навредив системе и чужим данным; (4) настроить инструменты так, чтобы они технически не выходили за границы; (5) корректно обращаться с конфиденциальной информацией и раскрытием.

2.1. Почему правила — это главное

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

Эта глава даёт систему, которая переводит эти вопросы в чеклист. В конце — «Чек-лист безопасного тестирования» (в приложениях книги), который вы проходите каждый раз.

Ничто в этой главе не является юридической консультацией. Законы различаются по юрисдикциям; при сомнениях консультируйтесь с юристом. Книга даёт инженерную дисциплину, а не правовую гарантию.

2.2. Как читать политику программы

Политика (program policy, brief) — это договор, по которому вы действуете. Читать её нужно целиком и буквально. Ключевые разделы:

Scope (границы). Что именно разрешено тестировать: домены, поддомены, приложения, API, иногда диапазоны. Бывает «wildcard» scope (*.example.com) и точечный (конкретные хосты).

Out of scope (вне границ). Что запрещено прямо: отдельные поддомены, сторонние сервисы, инфраструктура провайдера. Активы вне scope не тестируются даже если «технически доступны».

Запрещённые действия. Обычно: DoS/нагрузочное тестирование, спам, социальная инженерия сотрудников и пользователей, физические атаки, автоматическое агрессивное сканирование.

Правила раскрытия (disclosure). Можно ли и когда публиковать write-up; как правило — только с разрешения и после исправления.

Safe harbor. Обязательство не преследовать добросовестного исследователя (раздел 2.4).

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

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

2.2.1. Scope: разрешённое не значит «всё внутри»

Даже внутри разрешённого домена могут быть исключения: отдельные пути, функции «только для внутренних пользователей», интеграции со сторонними сервисами. Wildcard *.example.com не включает сервисы партнёров на других доменах и обычно не включает инфраструктуру хостинга. Правило простое: сомнение трактуется как «нельзя», а спорную границу уточняют у программы до тестирования.

2.2.2. Типичные out-of-scope находки

Многие программы заранее объявляют, что НЕ принимают (это не уязвимости в их модели риска): отсутствие отдельных security-заголовков без доказанного влияния, самоподписанные сертификаты на непроизводственных хостах, перечисление пользователей на страницах, где это по дизайну, «теоретические» CSRF на формах без значимого действия, сообщения об устаревших версиях без подтверждённой эксплуатации. Знание этого списка экономит время: такие отчёты закрывают как «informative» без вознаграждения.