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

Белое хакерство — итоги

НЕ ОБЯЗАТЕЛЬНО

FAQ — Часто задаваемые вопросы​

Типичные ситуации при отчёте и спорах с вендором, плюс ответы на частые запросы в поиске ("bug bounty как начать", "HackerOne", "CVSS", "white hat hacker"). Краткий ответ здесь; разбор — в главах раздела. Заучивание — в чек-листе.

Вопрос. Боюсь отправить отчёт — вдруг попаду в out of scope и меня привлекут.

Ответ. Сверьте цель с policy и scope программы (домены, типы багов, запреты на DoS и социнженерию). При сомнении спросите triage до активной эксплуатации. В РФ ключевое — согласие владельца и отсутствие умысла причинить вред; safe harbor в policy снижает риск, но не заменяет закон. Подробнее здесь — Белое хакерство — основы.

Вопрос. Отправил отчёт две недели назад — тишина, статус "New".

Ответ. Проверьте SLA программы, напишите вежливый follow-up с номером тикета и кратким резюме impact. Если сроки нарушены — эскалация через платформу (appeal) или security@ из security.txt. Не дублируйте тот же PoC десять раз. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. Программа закрыла отчёт как Duplicate — я уверен, что нашёл первым.

Ответ. Duplicate значит, что вендор уже знал о баге (внутренний тикет, другой исследователь, автоматический скан). Сохраните timestamps, скриншоты отправки и appeal с доказательством более раннего раскрытия, если policy это допускает. Повторная оплата за тот же root cause обычно не положена. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Уязвимость приняли Valid, но выплаты нет — "Informative" или $0.

Ответ. Разделите valid finding и payable: self-XSS, отсутствие заголовка без демонстрации exploit, best practice вне scope часто не платят. Перечитайте таблицу severity и исключения. Для карьеры Informative с хорошим write-up всё равно ценен в портфолио. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Можно ли в России легально тестировать чужой сайт без письменного договора?

Ответ. Ориентир — ст. 272 УК РФ и согласие владельца. Публичная Bug Bounty/VDP policy с safe harbor — форма согласия для описанного scope. Сканирование "просто так" чужого продакшена без policy — высокий правовой риск. Подробнее здесь — Белое хакерство — основы.

Вопрос. В scope только staging, а баг воспроизводится только на production — что делать?

Ответ. Не трогайте production без явного разрешения. Опишите гипотезу, приложите PoC со staging и спросите triage о расширении scope или внутренней проверке. Самостоятельная проверка прода вне policy — частая причина бана. Подробнее здесь — Программы Bug Bounty техгигантов.

Вопрос. Triage просит "меньше деталей в PoC" — боюсь, что без эксплойта закроют N/A.

Ответ. Дайте минимальный воспроизводимый шаг (один HTTP-запрос, один скриншот impact) и вынесите полный chain в приватное вложение или PGP. Не публикуйте weaponized exploit в комментариях. Баланс: достаточно для triage, без инструкции для массового злоупотребления. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. HackerOne отклонил регистрацию / программа недоступна для моей страны.

Ответ. Проверьте KYC, санкции и возраст в правилах платформы. Часть программ ограничивает резидентство; альтернатива — Intigriti, прямые VDP (security.txt), российские программы (Яндекс и др.). Для обучения — локальные лабы без выплат. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Нашёл RCE, паникую — сразу писать в Twitter?

Ответ. Сначала приватный отчёт через официальный канал, без публичных деталей и без массовой эксплуатации. Критичные баги ускоряют triage, но публикация до патча ломает CVD и репутацию. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Заказчик просит "проверить всё" без списка доменов — с чего начать scope?

Ответ. Зафиксируйте в письме или SoW: IP/домены, исключения, окна, запреты (социнженерия, фишинг сотрудников, DoS). Без этого любой находкой можно спорить post factum. Подробнее здесь — Белое хакерство — основы.

Вопрос. Burp ловит баг на "*.target.com" — поддомен вне списка в policy.

Ответ. Wildcard в policy (*.example.com) и фактический список часто расходятся. Остановитесь, уточните у triage; assumed scope — частая причина Invalid. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. Отчёт ушёл в Spam / закрыли как "Not applicable" без объяснения.

Ответ. Переотправьте по шаблону: Title, Product, Steps, Impact, CVSS. Уберите лишний сленг и вложения с малварью. Один тикет — одна уязвимость. Appeal с цитатой пункта policy. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. CVSS посчитал 9.8, программа выставила Medium — оспаривать?

Ответ. У платформ своя матрица severity (asset criticality, auth required, data sensitivity). Аргументируйте реальный impact на проде в scope, приложите сценарий атаки. Спор уместен, если есть факты, а не только калькулятор. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. Нужен ли CVE для Bug Bounty отчёта?

Ответ. Для triage достаточно класса слабости (CWE) и PoC; CVE присваивает вендор при CVD, если решит публиковать advisory. Не ждите CVE перед отправкой в программу. Подробнее здесь — Белое хакерство — основы.

Вопрос. Вендор исправил баг, но не ответил — можно ли публиковать write-up?

Ответ. Смотрите embargo и сроки CVD в policy (часто 90 дней после патча). Согласуйте redacted версию с security team. Преждевременный полный PoC — риск для пользователей и для вас в споре. Подробнее здесь — Когда доверие между вендором и исследователем ломается.

Вопрос. Коллега "подсказал" тот же баг — кто получит bounty?

Ответ. Обычно платят первому валидному отчёту по timestamp в портале. Совместные находки иногда делят по договорённости, если оба указаны при сабмите — уточняйте policy. Подробнее здесь — Когда доверие между вендором и исследователем ломается.

Вопрос. Сканер нашёл 500 находок — слать всё подряд в Bug Bounty?

Ответ. Нет: triage захлебнётся. Отберите ручную проверку, дедупликацию, один отчёт на root cause. Массовые автоматические репорты — путь к бану. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. Программа Microsoft / Google требует особый портал — отчёт из HackerOne не принимают.

Ответ. У техгигантов часто свой MSRC / bughunter и отдельные правила для продуктов (облако, мобильные SDK). Читайте policy конкретного продукта, а не общую страницу платформы. Подробнее здесь — Программы Bug Bounty техгигантов.

Вопрос. Хочу уйти в AppSec — с чего начать после первого Informative?

Ответ. Соберите 3–5 отчётов с чётким impact, пройдите PortSwigger, участвуйте в CTF, смотрите вакансии Junior AppSec / SOC. Сертификаты (eJPT, OSCP) — плюс, но портфолио отчётов важнее для многих команд. Подробнее здесь — Карьера в белом хакерстве.

Вопрос. Работодатель запретил Bug Bounty — можно ли участвовать в личное время?

Ответ. Проверьте трудовой договор и NDA: конфликт интересов, принадлежность находок, запрет на конкурентов. Юридически отдельное лицо, но увольнение и споры возможны. Подробнее здесь — Карьера в белом хакерстве.

Вопрос. Использовал агрессивный dirbuster — сайт лёг, меня забанили по IP.

Ответ. Многие policy запрещают DoS и высокочастотный fuzzing. Напишите triage, объясните rate limit, предложите retest с -t пониже. Для обучения — только свои лабы. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Нашёл утечку PII в ответе API — можно ли сохранить скриншот с паспортами в отчёте?

Ответ. Минимизируйте данные: замаскируйте идентификаторы, один redacted пример, удалите вложения после triage. Хранение чужих персональных данных у вас — отдельный правовой риск. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. VDP обещает "благодарность", но не деньги — имеет ли смысл?

Ответ. Да для репутации, Hall of Fame и первого опыта CVD; многие исследователи начинают с VDP, затем переходят на платные программы. Safe harbor при чётком scope так же важен, как выплата. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Chain из IDOR + SSRF — один отчёт или два?

Ответ. Обычно один отчёт с narrative chain и итоговым CVSS по combined impact. Раздельные тикеты рискуют duplicate и заниженной severity. Подробнее здесь — Как ищут и оформляют уязвимости.

Вопрос. Вендор угрожает судом после публикации статейи на Habr.

Ответ. Соберите переписку в портале, timestamps, policy safe harbor. Юридическая консультация обязательна; публичные кейсы 2025–2026 показывают ценность доказательной базы. Подробнее здесь — Когда доверие между вендором и исследователем ломается.

Вопрос. security.txt есть, а форма отчёта ведёт на 404.

Ответ. Попробуйте альтернативные контакты (HackerOne link в txt, security@, PGP). Зафиксируйте попытки доставки — это важно при споре о responsible disclosure. Подробнее здесь — Bug Bounty и координированное раскрытие.

Вопрос. Pentest-компания наняла меня — отчёты Bug Bounty в личном аккаунте конфликтуют с NDA клиента.

Ответ. Всё, что найдено на engagement клиента, идёт только заказчику по SoW. Личный BB по их активам без письма — нарушение NDA. Разделяйте аккаунты и scope письменно. Подробнее здесь — Карьера в белом хакерстве.

Вопрос. Bug bounty — что это и как начать новичку в 2026?

Ответ. Bug bounty — вознаграждение за валидные уязвимости в рамках policy программы. Старт: PortSwigger, первая VDP, затем платная программа с узким scope. Платформы и выплаты — глава 3, этика — глава 1.

Вопрос. Белый хакер — кто это и чем отличается от чёрного?

Ответ. Белый хакер ищет слабости с согласия владельца (договор, Bug Bounty, VDP) и сообщает через официальный канал. Ключ — намерение и разрешённый scope, а не набор утилит. Определения и закон РФ — глава 1.

Вопрос. HackerOne — как выбрать первую программу для практики?

Ответ. Фильтр Public, узкий scope, без агрессивных запретов на автоматизацию; читайте policy до сканирования. Регистрация и KYC — в правилах платформы. Обзор — глава 3, отчёт — глава 2.

Вопрос. Safe harbor в policy — что это даёт исследователю?

Ответ. Safe harbor — обещание вендора не преследовать за действия внутри описанного scope (без DoS, без чужих данных). Это не замена закона, но снижает риск спора. Разбор — глава 1, CVD — глава 3.

Вопрос. Scope bug bounty — как читать список доменов и wildcard?

Ответ. Сверяйте каждый хост с in-scope / out-of-scope, не расширяйте *.target.com без явного wildcard в policy. Сомнительный поддомен — вопрос triage до эксплуатации. Recon и Burp — глава 2, гиганты — глава 4.

Вопрос. CVSS 3.1 — как посчитать балл для отчёта на HackerOne?

Ответ. Калькулятор CVSS даёт базовый вектор; программа может занизить severity из-за asset criticality или обязательной аутентификации. Указывайте вектор и сценарий impact на проде в scope. Шаблон — глава 2.

Вопрос. CWE в отчёте — зачем указывать класс уязвимости?

Ответ. CWE (например CWE-639 для IDOR) ускоряет triage и маршрутизацию к нужной команде разработки. CVE для bounty обычно не обязателен на старте. Термины — глава 1, оформление — глава 2.

Вопрос. Responsible disclosure и CVD — в чём суть процесса?

Ответ. CVD — приватный отчёт → исправление → advisory/CVE по согласованию; сроки часто 45–90 дней. Публикация до патча ломает доверие. Процесс — глава 3, споры — глава 6.

Вопрос. Пентест или bug bounty — что выбрать компании?

Ответ. Пентест — фиксированный SoW, окно, ретест; bug bounty — непрерывный крауд с оплатой за valid finding. Часто сочетают. Контракт scope для пентеста — глава 1, платформы — глава 3.

Вопрос. Burp Suite Community — с чего начать поиск багов?

Ответ. Proxy → браузер → Repeater для одного запроса, Intruder осторожно (rate limit). Сохраняйте минимальный PoC, не десятки тысяч автоматических тикетов. Практика — глава 2.

Вопрос. IDOR — что это и как описать impact в отчёте?

Ответ. IDOR — доступ к чужим объектам по предсказуемому id без проверки владельца. Покажите два аккаунта и чтение/изменение чужих данных. Шаблон Title/Steps/Impact — глава 2.

Вопрос. XSS reflected и stored — платят ли в bug bounty?

Ответ. Платят за демонстрируемый impact (кража сессии, действие от имени жертвы), а не за alert(1) без сценария. Self-XSS часто Informative. Классификация — глава 2, выплаты — глава 3.

Вопрос. SQL injection — актуальна ли для bug bounty в 2026?

Ответ. Да на legacy и сложных API; чаще встречаются IDOR, SSRF, auth bypass. Автоматический sqlmap без ручной проверки — путь к N/A. Методология поиска — глава 2.

Вопрос. SSRF в облачных программах — на что смотреть в scope?

Ответ. Многие policy запрещают сканирование metadata (169.254.169.254) и внутренних сетей без разрешения. Опишите blind SSRF с DNS-callback, если разрешено. Облако гигантов — глава 4.

Вопрос. Bugcrowd и Intigriti — когда смотреть вместо HackerOne?

Ответ. Если программа exclusive на другой платформе или HackerOne недоступен по региону/KYC. Принципы те же: policy, scope, один root cause — один тикет. Обзор — глава 3.

Вопрос. Отчёт на русском или английском — что принимает triage?

Ответ. Глобальные программы чаще ждут английский; российские (Яндекс и др.) принимают русский при структуре Title/Steps/Impact. Технические термины (CWE, CVSS) — латиницей. Шаблон — глава 2, локальные программы — глава 4.

Вопрос. Яндекс Bug Bounty — как устроена программа для старта?

Ответ. Публичная policy, список сервисов in-scope, выплаты по severity; читайте запреты на социнженерию и DoS. Удобная первая локальная программа после лаб. Детали — глава 4.

Вопрос. Microsoft MSRC — куда слать отчёт вне HackerOne?

Ответ. У Microsoft свой портал MSRC и правила по продуктам (Windows, Azure, Office). Отчёт из чужой платформы могут не принять. Карта гигантов — глава 4.

Вопрос. Pentester и bug hunter — одна карьера или разные треки?

Ответ. Пентест — проектная работа в команде с отчётом заказчику; bug hunter — самостоятельные сабмиты и нестабильный доход. Навыки пересекаются (Burp, web). Роли и зарплаты — глава 5.

Вопрос. Red Team, Blue Team и bug bounty — как связаны?

Ответ. Red/Purple имитируют атакующего внутри организации; Blue/SOC — обнаружение; bug bounty привлекает внешних исследователей по policy. Шляпы и роли — глава 1, карьера — глава 5.

Вопрос. Google Bughunter и Apple Security Bounty — чем отличаются от стартапа?

Ответ. Отдельные порталы, строгий scope по продукту (мобильный SDK, облако), высокие выплаты и жёсткий triage. Читайте policy продукта, а не общую страницу. Сводка — глава 4.

Вопрос. Full disclosure — когда допустима публикация без согласия вендора?

Ответ. Крайняя мера при сбое CVD, игнорировании сроков и риске для пользователей; до этого — эскалация и доказательная база в портале. Риски публикации — глава 6, норма — глава 3.

Резюме раздела​

Белое хакерство — поиск и сообщение об уязвимостях с согласия владельца системы. От чёрного хакерства его отделяют намерение, договор (или policy программы) и канал отчёта, а не набор утилит.

CVE / CWE — язык общения с вендором; в отчёте указывают класс слабости и воспроизводимый PoC.

Пентест — проект с SoW и ретестом; Bug Bounty — краудсорсинг с выплатой за valid finding; VDP — легальный канал без обязательной оплаты.

CVD — приватный отчёт → патч → CVE/advisory; сроки часто 45–90 дней. Full disclosure — крайняя мера при сбое процесса.

Платформы — HackerOne, Bugcrowd, Intigriti; у гигантов свои порталы (MSRC, Google bughunter, Apple Security Bounty).

Карьера — AppSec, Red Team, SOC, консалтинг, независимый исследователь; вход через CTF, PortSwigger, первый легальный отчёт.

Конфликты (в т.ч. публичные кейсы 2025–2026) показывают ценность доказательной базы в портале и риски публикации эксплойта до патча.

Ключевые термины​

ТерминОпределение
ScopeРазрешённые цели и техники
Safe harborОбещание не преследовать за исследование в рамках policy
TriageПроверка и классификация отчёта
DuplicateУязвимость уже известна вендору
EmbargoЗапрет публичных деталей до патча
ChainНесколько багов → критичный impact

Маршрут по статьям​

  1. Основы — шляпы, закон РФ, Red/Blue/Purple, CVE
  2. Поиск и отчёт — recon, Burp, CVSS, шаблон, appeal
  3. Bug Bounty и CVD — платформы, выплаты, security.txt
  4. Техгиганты — Microsoft, Google, Apple, Яндекс, финтех
  5. Карьера — роли, зарплаты, сертификаты, книги
  6. Конфликты — prior disclosure, доказательства, метрики вендора
  7. Чек-лист

Следующие шаги​

Последнее обновление
Содержание