Одна глава из книги: «Исповедь баг-хантера: Взлом без лишней воды». Сейчас можно оформить предзаказ, по цене: 1499 руб. Цена, после релиза: 2200 руб.

Часть I. Вход в охоту

Глава 1. Исповедь баг-хантера

Раздел 1.1. Почему bug bounty - это ремесло

Если ты пришел сюда после просмотра голливудских фильмов, где хакер в черном худи яростно бьет по клавиатуре, а на экране бегут зеленые строчки кода, пока он за 30 секунд взламывает Пентагон - закрой эту книгу. Забудь этот бред. Реальность бьет по лицу сильнее, чем 403 Forbidden на самом сочном эндпоинте.

Bug bounty - это не магия. Это не врожденный дар, не секретный софт, который находит баги за тебя, и уж точно не легкая прогулка за легкими деньгами. Bug bounty - это ремесло. Тяжелое, монотонное, временами выводящее из себя, но чертовски увлекательное ремесло. И как в любом ремесле, здесь есть свои подмастерья, свои сканер-бои и свои настоящие мастера.

Иллюзия «Волшебной Кнопки»

Самая большая ошибка новичка - вера в тулзы. В автоматизацию ради автоматизации. Каждый день на платформы вроде HackerOne или Bugcrowd приходят тысячи «мамкиных хакеров». Они скачивают Nuclei, находят паблик-шаблоны, натравливают их на огромные скоупы корпораций и идут спать, надеясь проснуться миллионерами. Знаешь, что они получают утром? Бан IP-адреса от WAF и пачку репортов со статусом N/A (Not Applicable) или Spam.

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

Ремесленник знает свой инструмент досконально. Он не просто жмет «Scan» в Burp Suite Professional. Он отправляет запрос в Repeater и начинает методично, по одному символу, фаззить параметры. Он смотрит на заголовки ответа, анализирует задержки по времени (time-based векторы), замечает малейшие изменения в длине ответа (Content-Length). Он чувствует приложение кончиками пальцев.

Архитектура важнее эксплойта

Чтобы сломать вещь, нужно досконально понимать, как она устроена. Ты не сможешь найти хорошую SQL-инъекцию, если не понимаешь разницы между реляционными базами данных и NoSQL. Ты не раскрутишь SSRF (Server-Side Request Forgery) до RCE (Remote Code Execution), если не знаешь про внутренние метаданные облачных провайдеров (AWS, GCP). Ты не сможешь эксплуатировать OAuth-флоу, если не читал RFC и не понимаешь, как параметры state и redirect_uri защищают (или не защищают) пользователя.

Ремесло баг-хантера - это постоянное обучение. Это способность читать скучные спецификации, мануалы к непопулярным фреймворкам и старые посты на StackOverflow, чтобы понять, какую именно ошибку мог допустить уставший мидл-разработчик в три часа ночи пятницы.

Анатомия Ремесла: Практический Кейс

Давай разберем типичный пример того, как мыслит ремесленник в отличие от сканер-боя. Вот тебе мини-гайд, прямо как мы любим - быстро, грязно, эффективно.

Точка входа: Приватная программа, функционал загрузки аватара профиля. Сканер-бой закинет туда shell.php, получит ошибку Invalid file type, обидится и уйдет. Что делает ремесленник?

Что бросилось в глаза: Запрос летит на api.target.com/v1/user/avatar/upload. В теле запроса - multipart/form-data. Сервер проверяет расширение, MIME-тип и даже магические байты (Magic Bytes) файла. Вроде бы всё секурно. Эй, ты забыл про обфускацию и смежные векторы!

Векторы атак: Раз мы не можем залить шелл напрямую, давай проверим, как сервер обрабатывает метаданные. А что если сервер использует уязвимую библиотеку ImageMagick для ресайза картинок? Или ExifTool для чтения геолокации?

Команды: Перехватываем запрос в нашем любимом Burp Suite. Берем валидную JPG-картинку. Зашиваем в её EXIF-теги простейший payload для тестирования Blind Command Injection: exiftool -Comment='sleep 10' valid.jpg.

Эксплойты: Отправляем запрос. Ждем. Если ответ приходит ровно через 10 секунд - бинго! У нас выполнение команд на сервере. WAF - это не стена, а приглашение! WAF пропустил картинку, потому что это валидный JPG. Он не стал парсить EXIF.

Лайфхаки: Если WAF всё же режет популярные слова вроде sleep или curl, да ладно, это же очебаг-пантера! Используй альтернативы: ping -c 10 127.0.0.1 или обфусцируй payload через переменные окружения Linux ($@, ${IFS}). И главное: 0day - как любовь: если нашёл крутой байпас, молчи и юзай его тихо, пока не выжмешь максимум из скоупа.

Дисциплина, Боль и Тильт

Ремесло - это не только технические скиллы. Это психология. В bug bounty ты будешь проигрывать в 95% случаев. Ты будешь тратить недели на исследование огромного скоупа и не находить вообще ничего. Ты будешь находить шикарную уязвимость, писать идеальный репорт, отправлять его с дрожащими руками... и через пять минут получать обидный статус Duplicate (кто-то нашел это за час до тебя).

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

Профессионал (ремесленник) принимает правила игры. Он знает, что баг-баунти - это марафон, а не спринт. Если цель оказалась слишком «захарденной» (защищенной), он не бросает её со злости. Он сохраняет свои наработки, скрипты и структуру поддоменов в свой личный Notion или Obsidian. Он вернется к этой цели через пару месяцев, когда разработчики выкатят новый функционал или забудут закрыть тестовый сервер.

Твоя Личная Методология

У каждого крутого баг-хантера есть своя методология. Никто не работает вслепую. Ремесло подразумевает создание собственного конвейера:

1. Reconnaissance (Разведка): Сбор поддоменов, портов, эндпоинтов, JS-файлов. Максимально тихо и аккуратно.

2. Mapping (Картирование): Понимание логики приложения. Кто мы? Какие у нас права? С какими сторонними API общается сервис?

3. Discovery (Поиск): Точечное применение фаззеров, тестирование контроля доступа (IDOR, BOLA), манипуляции с параметрами.

4. Exploitation (Эксплуатация): Превращение мелкой ошибки в критическую уязвимость через цепочку багов (Chain exploit).

5. Reporting (Отчетность): Написание кристально чистого репорта, где триажеру не нужно гадать, как воспроизвести твой эксплойт.

Твоя задача на старте - не гнаться за P1 (критическими уязвимостями) и огромными выплатами. Твоя задача - поставить удар. Научиться находить информационные утечки, мелкие XSS, мисконфигурации. Научиться писать качественные отчеты. Научиться общаться с командой безопасности по ту сторону экрана.

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

Добро пожаловать в ремесло. Будет больно, но тебе понравится.

Раздел 1.2. Чем охота на баги отличается от «просто потыкать сайт»

В мире кибербезопасности есть два типа людей, которые ищут уязвимости. Первые - это туристы. Вторые - охотники. И разница между ними колоссальная, начиная от используемых инструментов и заканчивая размером выплат (payouts), которые они получают. Давай разберем это на молекулы, чтобы ты навсегда забыл привычку «просто тыкать сайт».

Синдром «Туриста с калашом»

Представь себе типичного новичка. Он посмотрел пару видео на YouTube с кричащими превьюшками вроде «ВЗЛОМАЛ GOOGLE ЗА 5 МИНУТ», скачал Kali Linux, открыл терминал и почувствовал себя Нео из Матрицы. Что он делает дальше? Он берет первый попавшийся домен из публичной bug bounty программы, открывает его в браузере и начинает пихать кавычки `'` или базовые пейлоады типа `"><script>alert(1)</script>` во все поля ввода, которые видит на главной странице.

Он кликает по ссылкам, запускает автоматические сканеры (Acunetix, Nikto, Nessus) на дефолтных настройках и ждет, когда из монитора посыплются доллары. Это и есть «просто потыкать сайт».

В чем проблема этого подхода?

1. Шум. Сканеры генерируют тысячи запросов в секунду. WAF (Web Application Firewall), даже самый базовый, детектит этот мусор за миллисекунды и кидает IP-адрес туриста в пермабан. Да, мы знаем, что WAF - это не стена, а приглашение, но зачем ломать дверь лбом, если можно аккуратно вытащить петли?

2. Поверхностность. Турист видит только верхушку айсберга - фронтенд (HTML, CSS, базовый JS) и формы обратной связи. Он не понимает, как данные ходят внутри системы, как взаимодействуют микросервисы, где находятся скрытые API и legacy-эндпоинты.

3. Отсутствие контекста. Если турист находит возможность выполнить XSS (Cross-Site Scripting) в поле, которое видит только он сам (Self-XSS), он бежит писать репорт, а потом искренне не понимает, почему ему влепили статус N/A (Not Applicable) и понизили репутацию на платформе.

Мышление Архитектора: Как работает Охотник

Охота на баги - это не про рандомные пейлоады. Это про реверс-инжиниринг логики разработчика. Охотник не «тыкает сайт». Он его препарирует.

Когда настоящий баг-хантер заходит на цель, он первые несколько дней вообще ничего не ломает. Он включает свой прокси (мой любимый Burp Suite Professional) и просто пользуется приложением как обычный, но очень дотошный юзер. Он регистрирует два аккаунта (с разными ролями, если это возможно), кликает каждую кнопку, перехватывает каждый запрос и внимательно смотрит на ответы сервера.

Он строит в голове (или в Obsidian/Notion) архитектуру приложения.

• На чем написан бэкенд? (Ruby on Rails, Node.js, Spring Boot?)

• Как реализована авторизация? (JWT, классические сессионные cookie, OAuth?)

• Есть ли балансировщики нагрузки? Как они проксируют запросы?

• Как фронтенд парсит данные? (React, Vue, Angular?)

• Где хранятся статические файлы? (AWS S3-бакеты, Cloudflare?)

Охотник ищет аномалии. Ему не интересны формы подписки на рассылку, потому что там ищут баги тысячи других новичков. Ему интересны сложные, многошаговые процессы: чекауты в корзинах, экспорт данных в PDF, интеграции со сторонними сервисами (SSO, Webhooks), обработка загружаемых файлов и сложные математические вычисления на стороне сервера.

Цепочки уязвимостей (Chaining)

Еще одно фундаментальное отличие. Турист мыслит одной уязвимостью. Охотник мыслит цепочками.

Допустим, на сайте есть уязвимость Open Redirect (возможность перенаправить пользователя на сторонний домен через параметр в URL, например ?next=https://evil.com). Турист отправляет репорт и получает 50 баксов или статус Informative, потому что импакт (влияние) от простого редиректа минимален.

Что делает охотник? Он смотрит, где еще этот редирект может выстрелить. А что если скомбинировать этот Open Redirect с механизмом авторизации OAuth? Он находит эндпоинт авторизации, подменяет redirect_uri на уязвимый параметр, заставляет жертву кликнуть по ссылке, и токен авторизации жертвы утекает на сервер хакера! Бинго! Из мусорного Open Redirect охотник собрал полноценный Account Takeover (ATO) и забрал P1 (Critical) выплату в 5000 долларов. Да ладно, это же очебаг-пантера! Все гениальное просто, если уметь связывать ниточки.

Практика: Анатомия Account Takeover

Чтобы слова не были пустым звуком, давай разберем классический пример того, как охотник превращает скучную функциональность в критическую дыру. Никакой магии, только логика и капля социальной инженерии. Как мы любим - быстро, грязно, эффективно.

Точка входа: Функционал «Забыли пароль?» (Password Reset). Самое банальное место в любом веб-приложении. Турист попытается вставить SQL-инъекцию в поле Email и сдастся.

Что бросилось в глаза: Охотник перехватывает запрос в Burp Suite. Он видит классический POST-запрос на /api/v1/password/reset с телом {"email": "victim@mail.com"}. Но охотник всегда смотрит на HTTP-заголовки. Он видит заголовок Host: target.com.

Векторы атак: Host Header Injection (Внедрение заголовка Host) с целью отравления ссылки для сброса пароля (Password Reset Poisoning).

Команды и эксплойты: Мы меняем оригинальный запрос.Вместо:Host: target.comМы пишем свой подконтрольный сервер: Host: evil-hacker.com И отправляем запрос.Что происходит на бэкенде? Разработчик, чтобы сгенерировать ссылку для сброса пароля, часто использует динамическое получение домена из заголовка Host (например, в PHP это $_SERVER['HTTP_HOST']). Сервер генерирует токен, кладет его в базу, склеивает со зловредным хостом и отправляет жертве письмо: Привет! Для сброса пароля перейди по ссылке: https://evil-hacker.com/reset?token=12345qwerty

Лайфхаки: Если сервер жестко проверяет заголовок Host и выкидывает 400 Bad Request, эй, ты забыл про обфускацию! Используй альтернативные заголовки, которые балансировщики нагрузки или прокси-серверы могут прокинуть на бэкенд с более высоким приоритетом:X-Forwarded-Host: evil-hacker.comX-Host: evil-hacker.comX-Forwarded-Server: evil-hacker.com

Жертва получает официальное письмо от легитимного сервиса, кликает по ссылке, её перекидывает на сервер хакера (где мы логируем токен), а затем мы прозрачно редиректим её обратно на настоящий сайт. Мы получили токен сброса пароля чужого аккаунта. Это P1. Это фулл-контроль. И помни: 0day - как любовь: если нашёл такую фичу в кастомном фреймворке, молчи и чекай её на всех поддоменах компании.

Репутация и Умение Читать Код

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

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

Баг-хантер пишет отчет, как RedTeam-документ. Он объясняет контекст. Он пишет четкие шаги для воспроизведения (Steps to Reproduce). Он прикладывает рабочий HTTP-запрос. Он записывает видео с доказательством концепции (PoC - Proof of Concept). Он объясняет реальное влияние уязвимости (Impact) на бизнес компании. Он не придумывает страшные сценарии, он показывает факты.

Охота на баги требует глубокого погружения. Ты должен стать параноиком, который во всем видит подвох. Если разработчик встроил фильтр на загрузку файлов, охотник думает: «А что, если загрузить файл с двойным расширением shell.php.jpg? А что, если изменить MIME-тип в заголовке? А что, если передать null-байт %00?». Охотник не верит UI. Охотник верит только сырому HTTP-трафику.

Перестань быть туристом. Перестань надеяться на удачный скан. Начинай вчитываться в JavaScript бандлы (используя тулзы вроде JSRoot или LinkFinder, чтобы вытаскивать скрытые эндпоинты API). Начинай понимать, как работает бизнес-логика. Именно там лежат самые сочные баунти, до которых никогда не доберутся автоматические сканеры и ленивые скрипт-кидди.

Раздел 1.3. Мышление исследователя

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

Мышление исследователя - это способность смотреть на систему не так, как задумал ее создатель. Разработчик строит дорогу от пункта А в пункт Б и ставит по краям заборчик. Обычный пользователь идет по дороге. Турист с калашом (о котором мы говорили в прошлой главе) пытается пробить забор головой, отправляя в форму логина 1' OR '1'='1. Исследователь же смотрит на забор, замечает, что под ним можно прокопать туннель, а потом вообще обходит систему с другой стороны, потому что разработчик забыл закрыть калитку на бэкенде.

Паранойя как профессиональный навык

Первый столп мышления исследователя - здоровая техническая паранойя. Ты никогда не должен верить тому, что тебе говорит фронтенд (клиентская часть приложения). Браузер - это территория, которую контролируешь ты. Сервер - это территория разработчика. Всё, что происходит в браузере, можно и нужно менять.

Представь, что ты покупаешь билет на самолет. Ты выбираешь место в бизнес-классе, и на экране загорается цена: $2000. Обычный человек достает кредитку. Скрипт-кидди пытается вставить XSS в поле «Имя пассажира». Что делает исследователь? Он перехватывает HTTP-запрос в Burp Suite и видит:POST /api/checkout{"ticket_id": "8472", "class": "business", "price": 2000}

Исследователь не верит цене. Он меняет 2000 на 1 (или на -2000, или на 0.0001) и отправляет запрос. Если сервер слепо доверяет данным от клиента и не перепроверяет цену по базе данных, бинго! Ты только что нашел уязвимость бизнес-логики. Эй, ты забыл про обфускацию здравого смысла, товарищ разработчик!

Исследователь всегда задает себе вопросы:

• «А что, если я отправлю массив вместо строки?»

• «А что, если я дважды отправлю один и тот же запрос параллельно (Race Condition)?»

• «А что, если я поменяю свой user_id на user_id админа в JWT токене?»

• «А что, если я пропущу шаг 2 в процессе регистрации и сразу отправлю запрос из шага 3?»

Анатомия Любопытства: Ломаем state-машину

Разработчики мыслят линейно. Они пишут код (state-машину) для идеального пользователя, который делает всё по инструкции. Мышление исследователя заключается в том, чтобы сломать этот порядок (flow).

Давай разберем это на классическом RedTeam-примере. Как мы любим - коротко, грязно, эффективно. Разберем обход двухфакторной аутентификации (2FA Bypass) через нарушение логики приложения.

Точка входа: Форма логина на финансовом портале.Что бросилось в глаза: Процесс входа состоит из трех этапов (endpoints):

1. /api/login (вводим логин и пароль). Сервер отвечает 200 OK и устанавливает куку session_id.

2. /api/2fa/verify (вводим код из SMS).

3. /api/dashboard (попадаем в личный кабинет).

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

Команды и эксплойты: Мы вводим логин и пароль жертвы (допустим, мы их подобрали или купили). Перехватываем ответ от /api/login. Видим, что сервер выдал нам куку. Вместо того чтобы вводить код из SMS на шаге 2, мы просто меняем URL в браузере (или в Repeater) напрямую на /api/dashboard, прикрепляя полученную куку. Если сервер не проверяет статус is_2fa_passed=true на каждом защищенном эндпоинте, а просто смотрит на наличие сессии - мы внутри. WAF - это не стена, а приглашение! Мы просто перешагнули через стену.

Лайфхаки: Если сервер жестко требует прохождения /api/2fa/verify, да ладно, это же очебаг-пантера - попробуй отправить запрос на проверку кода, но вместо POST метода используй GET, HEAD или OPTIONS. Или попробуй передать пустой параметр {"code": null}. Удивительно, как часто серверные фреймворки сходят с ума от пустых значений и пускают тебя дальше (Null Byte Injection в логике).

Дисциплина и Системность

Мышление исследователя - это не хаотичный поиск. Это жесткая система.Охотники ведут документацию. Ты не сможешь удержать в голове сотни параметров, поддоменов и эндпоинтов огромной корпоративной сети. Ты должен картировать поверхность атаки (Attack Surface Mapping).

Когда ты исследуешь цель, твой рабочий стол должен выглядеть как доска детектива. У тебя должны быть:

1. Mind map (Ментальная карта) функционала приложения.

2. Логи всех твоих запросов (Burp History).

3. Заметки о странном поведении (например: «Эндпоинт /api/v1/export возвращает 500 Internal Server Error, если передать спецсимволы в параметре format. Надо докрутить, возможен SSRF или инъекция»).

Новички часто бросают эндпоинт, если с первого раза не получили заветный алерт или шелл. Исследователь вгрызается в странности. Если сервер ведет себя нетипично (отвечает дольше обычного, выдает стектрейс ошибки, возвращает странные заголовки вроде X-Backend-Server) - это кровь в воде. Исследователь чует её и начинает копать именно там.

Умение Читать Между Строк

Чтобы находить баги, нужно понимать контекст бизнеса. Баг-хантер, который понимает, как компания зарабатывает деньги, найдет самые критичные уязвимости.

Если ты тестируешь стриминговый сервис (типа Netflix или Spotify), где главная ценность - контент по подписке, то уязвимость, позволяющая смотреть премиум-фильмы без оплаты (через манипуляцию с параметрами биллинга или API ключами мобильного приложения), будет оценена как Critical. Если ты найдешь там же банальную Self-XSS в профиле, тебе дадут статус Informative.

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

Искусство Задавать Вопросы

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

1. «Кто я для этой фичи?» (Авторизация, роли. Что будет, если я обращусь к ней без токена? Что будет, если я использую токен пользователя с низкими правами?)

2. «Откуда берутся данные?» (Параметры URL, заголовки, тело запроса. Доверяет ли сервер этим данным? Что будет, если я подсуну ему мусор?)

3. «Что происходит под капотом?» (Парсит ли он XML? Делает ли запросы к внутренней сети? Обращается ли к базе данных?)

И помни наше главное правило: 0day - как любовь: если нашёл крутую логическую дыру, молчи, документируй каждый шаг, делай безупречный PoC (Proof of Concept) и отправляй репорт. Триажеры обожают баги бизнес-логики, потому что их не находят сканеры, и они показывают реальный импакт на продукт.

Мышление исследователя - это привычка сомневаться во всем. Никогда не принимай правила игры, навязанные разработчиком. Ты здесь для того, чтобы эти правила переписать.

Раздел 1.4. Ложные ожидания новичка

Открой Twitter (или X, или что там сейчас в тренде). Вбей хештег #bugbounty. Что ты увидишь? Сплошной флекс. «Я нашел баг за 5 минут и получил $10,000!», «Мой первый P1 на HackerOne!», скриншоты с выплатами, яхты, крипта. Социальные сети продают тебе ошибку выжившего. Никто не постит скриншоты, где написано: «Я просидел 14 часов подряд, проверяя 200 поддоменов, получил три дубликата, два N/A и заработал ноль».

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

Иллюзия 1: «Сейчас скачаю сканер и он всё найдет»

Это классика. Приходит парень, читает пару статей, скачивает Nuclei, собирает паблик-шаблоны (templates) с GitHub и натравливает их на скоуп Apple или Yahoo. Он искренне верит, что сейчас автоматика найдет ему RCE в главном сервисе корпорации.

Что происходит в реальности? Корпорации с публичными программами сканируются такими же ботами 24/7. WAF (Web Application Firewall) этих компаний обучен отбивать дефолтные сигнатуры сканеров еще на подлете. Конечно, мы с тобой знаем, что WAF - это не стена, а приглашение. Но чтобы его обойти, нужно работать ручками, фаззить нестандартными символами, понимать логику обработки пакета. Скрипт-кидди на это не способен.

Итог: сканер находит какую-нибудь мусорную «уязвимость» вроде отсутствующего заголовка X-Frame-Options или открытого порта без реального вектора атаки. Новичок радостно строчит репорт. Триажер видит это, ставит статус Informative (или Spam) и режет репутацию аккаунта.

Запомни: автоматизация нужна для рутины (поиск поддоменов, сбор JS-файлов, проверка живых хостов). Автоматизация не ищет логические баги. Деньги платят за твой мозг, а не за то, что ты умеешь нажимать Enter в консоли.

Иллюзия 2: «Любой алерт - это критическая уязвимость»

«Эй, смотри, я вставил `<script>alert(1)</script>` в поле поиска, и окошко выскочило! Где мои 5000 долларов?» - кричит новичок, заливая репорт. Эй, ты забыл про обфускацию, контекст и здравый смысл!

Новички не понимают разницы между техническим фактом бага и бизнес-импактом (влиянием на бизнес). Тот факт, что ты смог выполнить JS-код в СВОЕМ собственном профиле (Self-XSS), где этот код не увидит ни один другой пользователь приложения, не стоит ничего. Компании не платят за баги. Компании платят за снижение рисков.

Если твой баг позволяет увести сессию админа, украсть базу кредиток или положить сервер - это P1 (Critical) и чемодан денег. Если твой баг позволяет тебе поменять цвет кнопочки в твоем личном кабинете - это мусор. Да ладно, это же очебаг-пантера! Учись докручивать баги до максимального импакта. Никогда не сдавай сырой alert(1). Докажи, что ты можешь через этот алерт сделать Account Takeover (ATO).

Иллюзия 3: «Дубликаты означают, что я неудачник»

Ты находишь шикарную IDOR (Insecure Direct Object Reference) на приватной программе. Ты потратил три дня, чтобы понять, как работает их кастомный API. Ты пишешь блестящий репорт, отправляешь его, предвкушая выплату... и через час получаешь статус Duplicate. Кто-то нашел это на две недели раньше, но разработчики еще не успели выкатить патч.

Новички в этот момент ломают клавиатуры. Они кричат о несправедливости и уходят из баг-баунти.

Профессионал знает: дубликат - это отлично. Да, ты не получил денег, но дубликат означает, что твой вектор атаки был верным. Ты нашел реальный, валидный баг, который компания признала. Ты мыслил в правильном направлении. Ты опоздал по времени, но технически ты отработал на 100%. Выдохни, сделай пометку в своей базе знаний, закрой ноут, сходи потрогай траву и возвращайся к следующей цели.

Иллюзия 4: «Я сразу буду ломать Google и Facebook»

Новичок открывает HackerOne, сортирует программы по размеру максимальной выплаты и идет ломать PayPal. Это как прийти в первый раз в спортзал и попытаться поднять штангу 200 кг. Тебя раздавит.

Программы с высокими баунти тестируются годами лучшими умами планеты (и топовыми синдикатами хакеров). Их поверхность атаки вылизана. Чтобы найти там баг, нужен уровень Senior+.

Где должен начинать ремесленник? В VDP (Vulnerability Disclosure Programs) - программах, где платят не деньгами, а репутацией, мерчем или просто говорят «спасибо». Да, звучит не секси. Но там ниже конкуренция. Там сидят админы, которые допускают базовые ошибки. Там ты можешь набить руку на написании репортов, понять, как общаться с триажем, и собрать свои первые валидные баги. Зашей это в свой план развития: первые 3-5 багов ищи ради опыта, а не ради кэша.

Практика: От иллюзии к реальности (Кейс)

Чтобы закрепить материал, давай разберем типичную ситуацию. Как действует новичок с ложными ожиданиями и как этот же сценарий отрабатывает тру-хантер. Мы же обещали без воды, верно? Только хардкор и RedTeam-отчет.

Точка входа: Приложение на React.js, в скоупе.

Что бросилось в глаза: Новичок запускает dirb или ffuf и находит директорию /.git/ на продакшен-сервере. Он переходит по ссылке target.com/.git/, получает 403 Forbidden, решает, что директория защищена, и уходит. Ошибка! WAF блочит листинг директорий, но файлы там могут лежать открыто.Векторы атак: Извлечение исходного кода (Source Code Disclosure) через доступные файлы репозитория.

Команды и эксплойты: Мы не стучимся в корень. Мы обращаемся к конкретным файлам. Перехватываем запрос в Burp и кидаем GET на target.com/.git/config. Оп! Сервер отвечает 200 OK и отдает нам конфиг с URL-адресами репозиториев разработчиков. Но мы идем дальше. Мы юзаем утилиту GitTools (или git-dumper):./gitdumper.sh https://target.com/.git/ output_dir/Утилита аккуратно вытягивает все коммиты, ветки и объекты, игнорируя 403-ю ошибку на корневой папке.

Лайфхаки: Новичок, стянув исходники, сразу пишет репорт «У вас открыт .git». Триажер дает за это низкий импакт (Low), так как исходники часто не содержат критичных данных. Что делает баг-хантер? Он использует trufflehog или Gitleaks на скачанном репозитории:gitleaks detect --source ./output_dir/Он находит захардкоженные AWS ключи (AWS_ACCESS_KEY_ID), которые разработчик случайно закоммитил два года назад. Баг-хантер проверяет ключи через AWS CLI, доказывает, что они дают доступ к S3-бакетам с данными клиентов, и сдает репорт на $15,000 с импактом Critical.

И помни наше главное правило: 0day - как любовь: если нашёл такую жирную цепочку, молчи, выкачивай всё, что нужно для PoC (но не ломай прод!), и только потом жми Submit Report.

Баг-баунти - это искусство терпения. Убери из головы быстрые деньги. Сфокусируйся на процессе, на реверс-инжиниринге чужого мышления, на понимании систем. Деньги придут как побочный эффект твоего мастерства. Добро пожаловать в реальный мир.