Kitobni o'qish: «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» без вознаграждения.

2.2.3. Worked-пример: разбор scope

Разберём типовую (вымышленная, обобщённая) формулировку scope, как её читает исследователь:

Что отсюда следует практически:

*.shop.example включает, например, admin.shop.example, но не включает blog.shop.example (явно исключён) и не включает api.shop.example? — включает, поддомен подходит под wildcard; при этом api.shop.example упомянут отдельно, что лишь подтверждает его в scope.

*.partners.shop.example — это другой узел дерева, явно вне scope: трогать нельзя, даже если доступен.

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

DoS и соц. инженерия запрещены вообще — даже «лёгкая» проверка нагрузкой выходит за правила.

Safe harbor привязан к соблюдению политики: шаг на partners.* или нагрузочный тест выводит из-под неё.

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

2.3. VDP и Bug Bounty: разные обещания

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

2.4. Safe harbor и его пределы

Safe harbor («тихая гавань») — раздел политики, где владелец обязуется не инициировать юридическое преследование исследователя, действующего добросовестно и в рамках правил. Это важная защита, но у неё есть пределы, которые нужно понимать:

Она действует только в границах программы. Шаг за scope — и защита не применяется.

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

Формулировки различаются: одни программы дают широкий safe harbor, другие — узкий и с оговорками. Читайте дословно, что именно обещано и при каких условиях.

«У них есть safe harbor» — не индульгенция. Защита обусловлена добросовестностью и соблюдением правил. Разрушение данных, выгрузка чужих персональных данных сверх необходимого, тестирование вне scope выводят вас из-под неё.

2.5. Принципы безопасного исследования

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

Минимальное воздействие. Подтверждайте уязвимость минимально достаточным PoC. Нашли SQL-инъекцию — достаточно извлечь одну «несанкционированную» строку, а не выгружать базу (сравните с лабораторией L-SQLI, где мы ограничиваемся парой записей для доказательства).

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

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

Без чужих учётных данных. Не вводите реальные чужие логины/пароли/токены. Для тестов используйте свои тестовые аккаунты (в HunterMart — предусмотренные учебные учётки).

Не в URL. Не помещайте персональные или секретные данные в URL и query-строки.

2.5.1. Опасные классы — особые меры

При тестировании SSRF, XXE, инъекций команд и десериализации легко случайно задеть внутреннюю инфраструктуру. Поэтому (подробно — главы 9 и 11):

используйте безопасные маркеры и, где можно, локальную лабораторию;

исключайте реальные внутренние адреса, облачные metadata-эндпоинты и чужие секреты;

не разворачивайте нагрузку, которая может нарушить работу сервиса.

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

2.6. Инструменты с техническими границами

Дисциплина «не выходить за scope» должна быть не только в голове, но и в коде инструментов. Автоматика, способная обратиться к произвольной цели, рано или поздно это сделает — по ошибке в списке целей, из-за редиректа или опечатки. Поэтому инструменты книги построены вокруг обязательного allowlist.

Пример — huntkit.safe_client (глава 12): клиент выполняет запрос, только если хост и порт входят в явный allowlist; пустой allowlist не разрешает ничего.

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

Allowlist по хосту (example.com) не покрывает его поддомены автоматически — это осознанный выбор в пользу явности. Если вам нужен поддомен, добавьте его явно. «Умное» сопоставление поддоменов чаще расширяет границу, чем помогает.

2.7. Раскрытие и репутация

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

Публичный write-up. После разрешённого раскрытия качественный разбор — ценный вклад и элемент портфолио. Отделяйте факты (что было) от интерпретаций и не раскрывайте лишних деталей о клиентах.

Коммуникация. С триажем общайтесь предметно и вежливо, даже при несогласии с оценкой. Репутация в этой сфере накапливается годами и открывает доступ к приватным программам и работе (глава 14).

2.7.1. Worked-пример: типичная временная линия раскрытия

Чтобы понимать, что и когда можно делать, полезно видеть процесс целиком (конкретные сроки задаёт политика программы — здесь обобщённая схема):

Обнаружение и подтверждение находки (в scope, по правилам).

Приватный отчёт через канал программы. С этого момента вы не раскрываете детали публично.

Триаж (программа подтверждает/уточняет/отклоняет; возможен дубликат).

Исправление уязвимости владельцем (может занять недели/месяцы).

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

Согласованное раскрытие (coordinated disclosure): публичный write-up — только с разрешения и обычно после исправления.

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

Молчание программы какое-то время — норма, а не повод для публичного раскрытия. Эскалация — через канал программы/платформы, а не через публикацию деталей.

2.8. Практикум

Уровень 1. Возьмите публичную политику любой известной VDP/Bug Bounty программы (как учебный материал для чтения, без какого-либо тестирования) и выпишите: scope, out-of-scope, запрещённые действия, наличие и формулировку safe harbor. Отметьте пункты, которые трактуете неоднозначно.

Уровень 2. Для HunterMart составьте собственный «scope»: какие эндпоинты существуют (см. карту лаборатории в главе 15), какие учётные записи вам разрешено использовать, какие действия вы считаете допустимыми в лаборатории. Это тренировка дисциплины на безопасной среде.

Уровень 4. Настройте huntkit.safe_client с allowlist только на 127.0.0.1:8000 и убедитесь, что попытка обратиться к любому другому хосту завершается DisallowedTargetError. Объясните, почему такая техническая граница надёжнее устной договорённости «я буду аккуратен».

2.8a. Дополнительные задания (уровни 1–5)

Уровень 1. Выпишите из учебной политики (как чтение) scope, out-of-scope и запреты.

Уровень 2. Для *.shop.example определите, что входит и что не входит в scope, с обоснованием.

Уровень 3. Сформулируйте, какие действия выводят вас из-под safe harbor, и почему.

Уровень 4. Настройте huntkit.safe_client на лабораторию и покажите блокировку чужого хоста.

Уровень 5. Опишите временную линию согласованного раскрытия для гипотетической находки.

2.9. Анализ ошибок новичка

Тестируют «немного за scope». Границы бинарны: либо разрешено, либо нет.

Полагаются на safe harbor как на индульгенцию. Он обусловлен добросовестностью и соблюдением правил.

Выгружают чужие данные «для убедительности». Это и вредно, и выводит из-под защиты; хватает PoC.

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

Доверяют дисциплину только памяти. Границы должны быть и в коде инструментов (allowlist).

2.10. Защитные меры (для владельца программы)

Пишите scope и out-of-scope однозначно; явно перечисляйте запрещённые действия.

Давайте внятный safe harbor — это повышает качество и количество отчётов.

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

Быстро и предметно реагируйте на отчёты: отзывчивость программы напрямую влияет на её результаты.

2.11. Резюме

Правила программы — это договор, который читают буквально и целиком: scope, out-of-scope, запреты, раскрытие, safe harbor. Safe harbor защищает, но только в границах и при добросовестности. Безопасное исследование — это минимальное воздействие, бережное обращение с данными, отказ от чужих учётных данных и деструктивных действий, а также технические границы в инструментах (обязательный allowlist). Приватное раскрытие и корректная коммуникация формируют репутацию, которая в этой профессии стоит дорого.

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

Какие разделы политики вы читаете до начала работы и почему именно их?

Что входит и что не входит в wildcard-scope *.example.com?

Назовите три предела safe harbor.

Почему минимальное воздействие — это одновременно этика и защита вашей «тихой гавани»?

Чем технический allowlist надёжнее устного обещания «быть аккуратным»?

Когда допустимо публиковать write-up и что в нём не стоит раскрывать?

2.13. Источники

OWASP Vulnerability Disclosure Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html (проверено 2026-10-19).

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

ISO/IEC 29147 (Vulnerability disclosure) и 30111 (Vulnerability handling) — стандарты процессов раскрытия и обработки; см. каталог ISO https://www.iso.org/ (проверено 2026-10-19).

«Чек-лист безопасного тестирования» — в приложениях книги.

Глава 3. HTTP, браузер, cookies, сессии, TLS и веб-архитектура

Цель главы. Дать рабочее понимание веб-стека на уровне, достаточном для исследователя: как устроена архитектура веб-приложения, как работает HTTP во всех значимых деталях, что такое cookies и сессии, как TLS защищает канал, и как всё это читать в трафике. Это фундамент для всех глав про уязвимости.

Предварительные требования. Главы 1–2. Базовое представление о том, что такое веб-страница.

Результаты обучения. Вы сможете: (1) описать путь запроса от браузера до сервера и обратно; (2) разобрать HTTP-обмен по частям и объяснить роль ключевых заголовков; (3) понимать cookies, сессии и их атрибуты безопасности; (4) объяснить, что даёт TLS; (5) анализировать security headers инструментом.

3.1. Архитектура веб-приложения

Современное веб-приложение — это распределённая система. Между вашим браузером и «сервером» обычно стоит несколько компонентов, и границы между ними — частый источник уязвимостей (главы 9, 11).

Типичный путь запроса:

Браузер — доверенная для пользователя, но недоверенная для сервера сторона. Всё, что приходит от браузера, сервер обязан считать потенциально враждебным (граница доверия, глава 1).

DNS — преобразует имя (huntermart.example) в IP-адрес.

CDN / обратный прокси — кэширование, балансировка, терминация TLS. Здесь рождаются классы вроде cache poisoning и request smuggling (главы по продвинутым темам).

Сервер приложения — исполняет бизнес-логику (в HunterMart — FastAPI).

База данных — хранилище (в HunterMart — SQLite).

Рисуйте для исследуемой системы диаграмму потоков данных с границами доверия (как DFD HunterMart в главе 1). Большинство уязвимостей живёт на границах, где данные переходят из менее доверенной зоны в более доверенную.

3.1.1. Клиент-серверная модель и SPA

Классическое приложение рендерит HTML на сервере. SPA (Single-Page Application) переносит рендеринг в браузер: сервер отдаёт JavaScript, который обращается к API (REST/GraphQL) за данными. Для исследователя это означает: много логики и эндпоинтов «спрятано» в JS-бандле (его анализ — глава 5), а безопасность смещается к API (глава 11) и клиентскому коду (глава 8).

3.2. HTTP: протокол запрос–ответ

HTTP (HyperText Transfer Protocol) — текстовый по происхождению прикладной протокол. Он без состояния (stateless): сам по себе не помнит предыдущие запросы; «память» (сессию) надстраивают поверх через cookies и токены (раздел 3.5).

3.2.1. Анатомия обмена

Любое HTTP-сообщение: стартовая строка, заголовки, пустая строка, опциональное тело. Пример на HunterMart:

Части запроса: метод (GET), цель (/api/orders/1001 + возможная строка запроса ?a=1), версия (HTTP/1.1), заголовки (Host обязателен в 1.1), тело (у GET обычно нет). Имена заголовков регистронезависимы.

3.2.2. Методы

* «Безопасный» здесь — термин HTTP (метод не меняет состояние), не про защищённость. Нельзя полагаться, что приложение честно соблюдает семантику: иногда GET меняет данные (проблема — CSRF, кэширование). Проверяйте фактическое поведение.

3.2.3. Коды состояния

2xx успех (200, 201, 204); 3xx перенаправление (301, 302, 304, 307, 308); 4xx ошибка клиента (400, 401, 403, 404, 429); 5xx ошибка сервера (500, 502, 503).

Для исследователя коды — сигнал, а не истина. 401 («не аутентифицирован») против 403 («нельзя»); 404 вместо 403 на чужом объекте — осознанная защита от перечисления (глава 6); разные коды/размеры на «есть/нет пользователя» — канал для перечисления учётных записей.

3.3. Заголовки и безопасность

Заголовки несут и метаданные, и защитные механизмы. Ключевые защитные заголовки ответа:

Некоторые заголовки, наоборот, раскрывают лишнее (Server, X-Powered-By — технология и версия). Проверять security headers вручную утомительно; инструмент huntkit.headers (глава 12) делает это по рекомендациям OWASP Secure Headers Project:

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

3.3.1. Worked-пример: разбор CORS

CORS (Cross-Origin Resource Sharing) — механизм, которым сервер разрешает чужим origin читать свои ответы (послабление Same-Origin Policy). Его часто путают с защитой от CSRF — это разные вещи: CORS управляет чтением ответа кросс-доменно, а не отправкой запроса. Ключевые заголовки ответа:

Опасная мисконфигурация — отражение Origin запроса в Access-Control-Allow-Origin вместе с Allow-Credentials: true:

Это позволяет странице атакующего читать ответы с учётными данными жертвы — утечка данных. Проверка: подставить произвольный Origin и посмотреть, отражается ли он в Allow-Origin при Allow-Credentials: true. Защита — allowlist доверенных origin, никогда не отражать произвольный Origin, не сочетать * с Allow-Credentials.

Access-Control-Allow-Origin: * без Allow-Credentials на публичном ресурсе (например, открытый API без сессии) обычно не уязвимость — читать там нечего приватного. Подтверждение требует доступа к приватным данным кросс-доменно.

3.4. Строка запроса, тело и форматы данных

Строка запроса (query string) — ?key=value&key2=value2. Видна в логах и истории — не место для секретов (глава 2).

Тело — у POST/PUT/PATCH. Частые типы: application/json, application/x-www-form-urlencoded, multipart/form-data (загрузка файлов, глава 9).

JSON — основной формат API. REST — архитектурный стиль над HTTP; GraphQL — единый эндпоинт с языком запросов; WebSocket — полнодуплексный канал. Все три разбираются в главе 11.

3.5. Cookies и сессии

Поскольку HTTP без состояния, сервер выдаёт cookie заголовком Set-Cookie, а браузер возвращает её в Cookie:

Атрибуты cookie — это механизмы безопасности:

HttpOnly — недоступна из JavaScript (смягчает кражу сессии при XSS, глава 8).

Secure — отправляется только по HTTPS.

SameSite (Lax/Strict/None) — ограничивает отправку в межсайтовых запросах (ключ к защите от CSRF, глава 8).

Path/Domain — область действия; слишком широкий Domain — риск.

Сессии и токены. Идентификатор сессии хранят в cookie (серверная сессия) или в виде токена в Authorization (как в HunterMart). Учебная модель HunterMart упрощена (без срока жизни и ротации) — её ограничения разбираются в главе 10.

3.5.1. Worked-пример: полный цикл аутентифицированной сессии

Разберём на HunterMart цикл «вход → аутентифицированный запрос» целиком, по трафику. Шаг 1 — вход:

Сервер проверил учётные данные (аутентификация) и выдал токен сессии. HunterMart передаёт токен в теле ответа, и клиент предъявляет его в заголовке Authorization (другие приложения кладут сессию в Set-Cookie — тогда браузер возвращал бы её автоматически, см. 3.5). Шаг 2 — аутентифицированный запрос:

Что здесь важно исследователю: (1) токен — это и есть «состояние», надстроенное над HTTP без состояния; (2) предъявление токена подтверждает личность (аутентификация), но не гарантирует право на объект 1001 — это отдельная проверка (авторизация, глава 6); (3) если убрать Authorization, сервер должен вернуть 401 — проверьте это, чтобы понять, где граница аутентификации. Воспроизвести цикл в терминале:

3.6. Редиректы

Ответ 3xx с Location перенаправляет браузер. 301/308 — постоянный, 302/307 — временный; 307/308 сохраняют метод и тело, 302 исторически часто меняет метод на GET. Редиректы — источник Open Redirect (если цель берётся из управляемого параметра без проверки). В HunterMart это эндпоинт /go (разобран как лаборатория L-OPENREDIR; подробности класса — в части про уязвимости):

3.7. Версии протокола

HTTP/1.1 — текстовый, один активный обмен на соединение (с keep-alive). Обязателен Host. Расхождения в разборе 1.1 между прокси и сервером порождают request smuggling.

HTTP/2 — бинарный, мультиплексирование потоков, сжатие заголовков (HPACK). Семантика та же.

HTTP/3 — поверх QUIC (на UDP), TLS 1.3 встроенно, устраняет head-of-line blocking на транспорте.

Для большинства находок уровня приложения версия транспорта вторична (семантика сохраняется), но на стыках версий и реализаций возникают smuggling и рассинхрон кэша.

3.7.1. Worked-пример: почему стыки версий опасны

Проблема рождается, когда два компонента на пути (например, фронтенд-прокси/CDN и бэкенд-сервер) по-разному интерпретируют одно и то же сообщение. Классический пример — HTTP Request Smuggling: прокси и сервер расходятся в том, где заканчивается один запрос и начинается следующий (из-за разной трактовки Content-Length и Transfer-Encoding в HTTP/1.1, или при трансляции HTTP/2→HTTP/1.1). В результате «протащенный» фрагмент одного запроса влияет на другой — например, на запрос другого пользователя.

Для исследователя практический смысл в том, что такие классы живут не в коде приложения, а в расхождениях реализаций на границе компонентов. Поэтому важно знать, что перед приложением стоит (CDN, обратный прокси) и как устроена трансляция версий. Это продвинутая тема; здесь достаточно понимать принцип: единая семантика HTTP не гарантирует единую интерпретацию байтов разными реализациями, и именно расхождение интерпретаций — источник уязвимости.