Как я участвовал в Bug Bounty в 2026 году: чему меня научил Black Box-анализ веб-приложения крупной IT-компании

«Самое сложное в Bug Bounty — не найти подозрительное место, а доказать, что оно действительно является уязвимостью.»

В начале 2026 года я решил проверить одну простую гипотезу: насколько сложно сегодня найти проблему безопасности в современном веб-приложении крупной компании, имея только браузер и DevTools.

Для этого в рамках одной из программ Bug Bounty я провёл ручной Black Box-анализ клиентской части веб-приложения одной из крупных российских IT-компаний.

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

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

---

Black Box сегодня — это уже не поиск XSS за пять минут

Когда слышишь словосочетание Bug Bounty, в голове обычно возникает простой алгоритм :

1. Открыли портал;

2. «Потыкали» все видимые поля с input и query параметры на предмет XSS;

3. Зашли в DevTools;

4. Нашли XSS;

5. Получили выплату||уважение, проснулись*

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

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

---

Методология моего исследования

Исследование проводилось полностью вручную. Использовались только стандартные возможности Chrome DevTools:

Скрытый текст

• Network;

• Sources;

• Console;

• Application;

• анализ HTTP-заголовков;

• исследование DOM;

• анализ Cookies;

• проверка Content Security Policy;

• анализ взаимодействия через iframe и postMessage.

Никаких автоматизированных сканеров. Никакого фаззинга. Никаких попыток воздействовать на серверную инфраструктуру.

---

Первая находка — postMessage

Одной из первых конструкций, которая привлекла внимание, оказался следующий вызов:

window.parent.postMessage(data, "*");

Для любого опытного QA или AppSec-инженера такая строка выглядит подозрительно. Использование "*" означает, что сообщение может быть отправлено любому родительскому окну.

Первая мысль была очевидной:

Похоже, нашел проблему.

Но после более детального анализа стало понятно, что всё значительно сложнее.

Само по себе использование "*" не является уязвимостью.

Всё зависит от контекста:

• Передаются ли чувствительные данные?

• Можно ли встроить приложение в сторонний iframe?

• Проверяет ли принимающая сторона event.origin?

Если ответы на эти вопросы отрицательные, эксплуатация становится либо невозможной, либо крайне маловероятной.
В моем случае удалось установить, что принимающая сторона проверяет event.origin.

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

---

Вторая находка — CSP оказалась не такой строгой, как я ожидал

Следующей интересной находкой стали значение директив найденных в политике Content Security Policy, использованной на портале.

В конфигурации присутствовали директивы:

unsafe-inlineunsafe-eval

Это не означает наличие XSS уже сейчас. Однако если подобная уязвимость когда-либо появится, браузер уже не сможет использовать CSP как полноценный дополнительный уровень защиты

---

Третья находка — Cookies оказались интереснее, чем предполагалось

Следующим этапом исследования стала проверка cookies.

Первое, что делает любой исследователь:

document.cookie

Несколько cookies действительно были доступны через JavaScript.
На первый взгляд это могло оказаться проблемой, но после анализа выяснилось, что все cookies, связанные с аутентификацией, были защищены корректно, через HttpOnly.

Оставшиеся доступные cookies использовались для аналитики и пользовательских настроек.
То есть сама по себе их доступность JavaScript не являлась ошибкой.

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

---

Оформление отчета и коммуникация с компанией

По итогам исследования был подготовлен технический отчёт и направлен владельцу портала в рамках процесса Responsible Disclosure, через портал standoff365 Bug Bounty, который был указан у компании как целевое средство коммуникации.

В отчёт вошли:

• анализ клиентской архитектуры безопасности;

• наблюдения по реализации postMessage;

• рекомендации по усилению Content Security Policy;

• анализ конфигурации cookies;

• предложения по дополнительному hardening клиентской части.

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

Примерно через три календарных дня, я получил ответ от представителей компании — «О перечисленных проблемах мы уже знаем. В целом все описанные проблемы сами по себе имеют низкий security impact и обычно не претендуют на вознаграждение в рамках баг баунти программы» (С), это меня не расстроило, так как я изначально подчеркивал в отправленном им отчете, что на вознаграждение я не претендую, ввиду того , что чувствительных уязвимостей я не нашел.

---

Ожидаемый вывод

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

Я потратил 7 часов выходного дня на анализ портала, 2 часа на оформление и сдачу отчета и это стоило того, хотя бы в рамках того, что удалось понять архитектуру/особенности работы веб приложения, верхнеуровнево оценить запас его прочности и по коммуницировать с коллегами из крупной компании, хоть и в ограниченном формате.

Подобная гимнастика для мозга полезна как самому исследователю, так и компаниям участвующим в программах Bug Bounty. Ведь первым это может принести кроме удовлетворения потребности в исследовании денежное вознаграждения в случае аппрува со стороны компании, а вторым возможность выявления и устранения дефектов пропущенных на этапе ПСИ.

PS

Публикация сделана после завершения процесса ответственного раскрытия и без раскрытия технических деталей, позволяющих воспроизвести исследование.