Добро пожаловать! Если вы читаете это, значит вы, скорее всего, исследуете безопасность нашего проекта. Мы высоко ценим ваш интерес к защите PyyplBot и готовы вознаграждать найденные уязвимости. Пожалуйста, внимательно ознакомьтесь со всеми правилами, прежде чем приступать к исследованию.
О нашем проекте
PyyplBot — это платформа, призванная упростить и автоматизировать взаимодействие пользователей с финансовыми сервисами. Мы стремимся обеспечивать высокий уровень безопасности и делаем всё возможное, чтобы защищать интересы наших клиентов.
Политика вознаграждений
Первый исследователь
Награду может получить первый исследователь, сообщивший об неизвестной ранее валидной уязвимости. В качестве вознаграждения мы предлагаем денежные выплаты и фирменные подарки.
Оценка критичности
Мы оцениваем уязвимости в индивидуальном порядке, ориентируясь на CVSS и нашу внутреннюю экспертизу. Уровень критичности может быть понижен или повышен, исходя из потенциального ущерба при эксплуатации и сложности атаки.
Примерные диапазоны вознаграждений
Точная сумма определяется в зависимости от конкретного случая и вклада исследователя. Менее серьёзные проблемы без существенного влияния на безопасность могут быть вознаграждены по нашему усмотрению.
Как сообщить об уязвимости
1. Убедитесь в реальности угрозы
Важно, чтобы найденная проблема действительно влияла на безопасность пользователей, инфраструктуры или данных.
2. Подготовьте детальный отчёт
• Чёткие шаги воспроизведения уязвимости.
• Потенциальные последствия и риски.
• Любые дополнительные материалы (скриншоты, логи, видео).
3. Отправьте информацию нам
•
• Через Telegram: Контакты
Пожалуйста, укажите в сообщении «Bug Bounty», чтобы мы могли оперативно обработать ваш отчёт.
Ответственное раскрытие
• Просим вас не публиковать детали обнаруженной уязвимости до тех пор, пока мы не подтвердим её и не примем меры по исправлению.
• Используйте обнаруженные уязвимости исключительно в мирных целях и только для укрепления безопасности PyyplBot.
• Если вы хотите обнародовать информацию, дождитесь нашего разрешения или предоставьте нам разумный срок для устранения проблемы.
Правила программы
1. Подробные отчёты
• Составляйте максимально детальные отчёты, описывающие рабочие шаги воспроизведения и сценарий атаки.
• Если отчёт недостаточно подробен, чтобы мы могли воспроизвести проблему, он может быть отклонён от права на вознаграждение.
2. Ограничения при поиске уязвимостей
• Не нарушайте конфиденциальность, целостность данных и доступность наших сервисов.
• Не проводите автоматизированный перебор, атаки на отказ в обслуживании (DoS/DDoS), не рассылайте спам нашим пользователям.
• Запрещены любые виды социальной инженерии и фишинга против наших сотрудников и подрядчиков.
• При использовании сканеров не превышайте частоту 10 запросов в секунду.
• Тестируйте исключительно на собственных учётных записях. Не пытайтесь получить доступ к чужим аккаунтам или чужой конфиденциальной информации.
• Применяйте минимально возможный PoC для подтверждения уязвимости. Если тестирование может повлиять на работу системы или пользователей, согласуйте его с нами.
3. Обработка дубликатов
• В случае, если несколько человек сообщат об одной и той же уязвимости, вознаграждение получает только первый, кто прислал полноценный отчёт.
• Если уязвимость уже известна и мы занимаемся её исправлением, она не будет претендовать на вознаграждение.
4. Конфиденциальность
• Не разглашайте информацию об обнаруженной уязвимости без нашего одобрения.
• Публичные 0-day уязвимости с официальным патчем, выпущенным менее 2 месяцев назад, могут рассматриваться как дубликаты, если данные о них уже общедоступны.
5. Особые условия тестирования (RCE, SQLi, LFI и т.д.)
• При обнаружении RCE, SQLi, LFI, LFR, SSTI допускается только минимальный PoC: например, использование команды sleep, чтение /etc/passwd или небольшой сетевой запрос (curl), которые подтверждают факт уязвимости без нанесения вреда системе.
Направления поиска
1. Сферы интереса
Нас интересуют уязвимости во всех наших продуктах.
2. Серверные уязвимости
Вознаграждаются только критические уязвимости на стороне сервера, если:
• Они ставят под угрозу инфраструктуру (RCE, SQLi, LFR, SSRF и т.д.),
• Или приводят к утечкам персональных или чувствительных данных.
3. Уязвимости на стороне клиента
Такие уязвимости (например, XSS, CSRF) и проблемы бизнес-логики (например, повышение привилегий) принимаются, но не вознаграждаются.
4. Уязвимости на других доменах
Могут быть рассмотрены, однако решение о вознаграждении принимается на наше усмотрение.
Что не рассматриваем как уязвимость
• Не относящиеся к безопасности проблемы.
• Любые формы социальной инженерии и фишинга.
• XSS, CSRF, неправильная настройка CORS, clickjacking, tabnabbing без реального влияния на безопасность.
• Использование сторонних компонентов с известными уязвимостями без реального вектора атаки.
• Автоматические результаты сканеров, не подтверждённые демонстрацией реального риска.
• Отчёты без чёткого указания на существование уязвимости.
• Отчёты без демонстрации возможных негативных последствий.
• Атаки, требующие полноценного перехвата трафика (MITM).
• Раскрытие IP-адресов, DNS-записей и открытых портов.
• Отчёты о небезопасных шифрах SSL/TLS без демонстрации эксплуатации.
• Физические атаки на собственность или дата-центры.
• Инъекции формул CSV.
• Проблемы с CSP (или её отсутствием), не влияющие напрямую на безопасность.
• Наличие атрибута автозаполнения в веб-формах.
• Отсутствие Rate Limit без доказанного влияния на безопасность.
• Наличие или отсутствие записей SPF, DKIM.
• Уязвимости, связанные с политикой паролей и аутентификационными данными, если нет реального риска.
• Возможность декомпилировать приложения (реверс-инжиниринг), если это не даёт критичных преимуществ злоумышленнику.
Не считаются критичными (не подлежат оплате)
• Общие рекомендации по улучшению безопасности (best practices).
• Отсутствие определённых заголовков безопасности и флагов cookie, если нет сценария реальной атаки.
• Теоретические атаки без доказательств возможности эксплуатации.
• Подмена контента и любая текстовая инъекция, кроме HTML-инъекции.
• Раскрытие нечувствительной технической информации, версий ПО и проч.
• Уязвимости в сторонних продуктах, не затрагивающие безопасность PyyplBot.
• Уязвимости, требующие прав суперпользователя или физического доступа к устройству.
• Уязвимости, проявляющиеся только в устаревших или заведомо уязвимых браузерах и ОС.
• Уязвимости «self‑harm», при которых вред может нанести только сам пользователь себе.
• Email-спам, если злоумышленник не может управлять содержимым письма и вставлять вредоносные ссылки.
• XSS в заголовках (Host, User-Agent, Referer и т.д.).
• Уязвимости в сервисах партнёров, не влияющие на нашу инфраструктуру и данные.
• Уязвимости на мобильных устройствах, требующие root-доступа, jailbreak и т.д.
• Раскрытие публичных API ключей, не имеющих критических функций.
• Сценарии скриптинга в PDF без доказательства практической уязвимости.
Требования к отчёту
Отчёт об уязвимости должен содержать:
1. Описание — краткое, но чёткое объяснение сути проблемы.
2. Шаги воспроизведения — инструкция, позволяющая воспроизвести уязвимость (например, последовательность HTTP-запросов, пошаговые скриншоты и т.д.).
3. Возможные последствия — к чему может привести эксплуатация уязвимости.
4. Рекомендации по устранению — при желании вы можете описать, как с вашей точки зрения можно исправить проблему.
Мы рассмотрим ваш отчёт в течение 14 рабочих дней и сообщим результаты проверки.
Заключение
Благодарим всех исследователей, желающих помочь в повышении безопасности PyyplBot. Ваш вклад позволяет нам своевременно устранять потенциальные угрозы и обеспечивает сохранность данных пользователей. Мы ценим каждое сообщение и надеемся на взаимовыгодное сотрудничество!
Если у вас остались вопросы или вы хотите сообщить об уязвимости, пожалуйста, свяжитесь с нами любым удобным способом:
•
• Telegram: Контакты
Пожалуйста, не забудьте указать «Bug Bounty» в сообщении. Желаем вам успешных исследований и благодарим за стремление сделать наш проект безопаснее!
