В данный момент участвовать в программе могут только индивидуальные предприниматели и самозанятые. Тинькофф компенсирует 6% налоговых потерь.

Добро пожаловать в Bug-Bounty Тинькофф!

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

Оглавление

• Область действия

1. Где искать уязвимости?
2. Какие уязвимости искать?
3. Что не нужно присылать?
4. Что не претендует на вознаграждение?

• Правила участия

1. Общие правила
2. Правила тестирования
3. Политика раскрытия информации об уязвимостях
4. Идентификация трафика
5. Политика тестирования RCE
6. Политика тестирования SQL инъекций
7. Политика загрузки и чтения файлов

• Вознаграждения

1. Таблица выплат
2. Определение критичности уязвимости
3. Благотворительность
4. Примечания

• FAQ

1. Как составить хороший отчет?
2. Предоставляются ли учетные данные для тестирования?
3. Как и в какие сроки проверяются отчеты?
4. Как осуществляется работа с дубликатами?

Область действия

Где искать уязвимости?

Уязвимости можно искать на всех наших ресурсах, а именно — *.tinkoff.ru, *.tcsbank.ru, *.tinkoffinsurance.ru. Однако максимальные выплаты подразумеваются только за обнаружение проблем в нижеперечисленных сервисах. Все остальные ресурсы идут с пониженным (в некоторых случаях нулевым) коэффициентом для вознаграждения.
Основные домены и мобильные приложения следующих сервисов:

• Тинькофф Банк
• Тинькофф Инвестиции
• Тинькофф Бизнес
• Тинькофф Мобайл
• Тинькофф ID
• Тинькофф Мессенджер
• Тинькофф Страхование
• Тинькофф Путешествия
• Тинькофф Работа
• Тинькофф Платежи

Обратите внимание, что вторичные домены вышеупомянутых сервисов не входят в основную область действия.

Какие уязвимости искать?

Мы в первую очередь заинтересованы в критичных уязвимостях на стороне сервера. При этом нахождение других типов уязвимостей также приветствуется. Если вы сомневаетесь, стоит ли связываться с нами по поводу обнаруженной проблемы, посмотрите, нет ли ее в списке "Что не нужно присылать?". В случае, если она там отсутствует, смело отправляйте отчет с детальным описанием проблемы. Информацию о том, как лучше сообщить об уязвимости, можно найти в графе FAQ.

Ниже приведены примеры уязвимостей, за которые мы с радостью выплатим вознаграждение (список далеко не полный):

• Удаленное исполнение кода (RCE);
• Инъекции (например, SQL-инъекции или XML-инъекции);
• LFR/LFI/RFI;
• SSRF;
• Утечки памяти;
• Уязвимости бизнес-логики;
• IDOR;
• Уязвимости контроля доступа;
• Раскрытие чувствительной информации;
• Угон аккаунта;
• Недостатки аутентификации/авторизации;
• XSS и CSRF с воздействием на чувствительные данные.

Что не нужно присылать?

• Сообщения об уязвимостях в сервисах, не относящихся к экосистеме Тинькофф;
• Сообщения о мошеннических схемах, злоупотреблении легитимным функционалом (такие сообщения рекомендуем присылать в чат поддержки, вознаграждение за подобные репорты в рамках баг-баунти не полагается);
• Проблемы, никак не связанные с безопасностью;
• Сообщения о возможных DDOS-атаках;
• Информацию об IP-адресах, DNS-записях и открытых портах;
• Сообщения о применении фишинга и других техник социальной инженерии;
• Отчеты сканеров уязвимостей и других автоматизированных средств;
• Сообщения о публично доступных панелях входа;
• Clickjacking;
• Разглашение публичной информации о пользователях;
• Сообщения о недостатках использования 4-х символьных смс-кодов;
• Сообщения о неправильной реализации округлений на конверсионных переводах между расчетными, накопительными и брокерскими счетами (на такие транзакции установлены лимиты);
• Обход проверки на root и jailbreak;
• Сообщения о возможности обратной разработки мобильный приложений.

Что не претендует на вознаграждение?

• Self-XSS, XSS в непопулярных или устаревших браузерах, Flash-based XSS;
• CSRF и XSS без воздействия на чувствительные данные;
• Отсутствие рекомендованных механизмов защиты* (например, HTTP заголовков безопасности, флагов безопасности cookie или защиты от CSRF);
• Ошибки в настройке CORS*;
• Использование устаревшего или потенциально уязвимого стороннего ПО*;
• Атаки, связанные с мошенничеством или кражей;
• Возможность неограниченной отправки СМС и email;
• Атаки типа DOS*;
• Небезопасно сконфигурированные TLS или SSL*;
• Разглашение информации о существовании в системе данного имени пользователя, email или номера телефона;
• Full Path Disclosure;
• Разглашение технической или нечувствительной информации* (например, версии продукта или используемого ПО, stacktrace);
• Open Redirect без дополнительного вектора атаки (например, кражи токена авторизации);
• Подмена контента на странице;
• Tabnabbing;
• Уязвимости, требующие выполнения сложного или маловероятного сценария взаимодействия с пользователем;
• Уязвимости, необходимым условием эксплуатации которых является наличие вредоносного ПО, root-прав или jailbreak на устройстве;
• Атаки, требующие MITM чужого соединения или физической близости с чужим устройством (например, атаки через NFC, Bluetooth, Wi-Fi и shoulder surfing);
• Маловероятные или теоретические атаки без доказательств возможности их осуществления

* — без детального описания вектора атаки и доказательств потенциального нанесения ущерба или вреда.

Правила участия

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

Общие правила

• Область действия bug-bounty программы ограничивается техническими уязвимостями в сервисах компании. Если вы столкнулись с проблемами, которые никак не связаны с безопасностью, обратитесь в службу поддержки клиентов.
• При обнаружении 0-day или 1-day уязвимости, официальный патч которой был менее недели назад, выплата награды осуществляется на усмотрение команды безопасности Тинькофф и рассматривается в каждом конкретном случае.

Правила тестирования

• Для проведения тестирования используйте только свои собственные учетные записи либо учетные записи пользователей, который явно выразили свое согласие. Не пытайтесь получить доступ к чужим аккаунтам или любой конфиденциальной информации.
• Во время поиска уязвимостей следует избегать нарушения конфиденциальности, целостности и доступности информации в наших сервисах.
• Запрещена любая деятельность, которая может нанести ущерб приложениям компании, ее инфраструктуре, клиентам и партнерам. Примеры запрещенных действий: социальная инженерия, фишинг, атаки типа "Отказ в обслуживании", физическое воздействие на инфраструктуру.
• Для подтверждения наличия уязвимости используйте минимально возможный POC (Proof of Concept). В случае, если это может повлиять на других пользователей или же работоспособность системы, свяжитесь с нами для получения разрешения. Дальнейшая эксплуатация уязвимостей строго запрещена.
• Автоматическое сканирование должно быть ограничено 5 запросами в секунду.

Политика раскрытия информации об уязвимостях

• Запрещено раскрывать уязвимости или делиться какими-либо подробностями без письменного разрешения команды безопасности Тинькофф.
• Мы оставляем за собой право отклонить любой запрос на публичное раскрытие отчета.

Идентификация трафика

Существует вероятность того, что трафик, сгенерированный внешними исследователями безопасности, может быть классифицирован как вредоносный. Для предотвращения возникновения связанных с данным фактом проблем, пожалуйста, добавляйте следующий HTTP заголовок ко всем исходящим запросам — X-Bug-Bounty: Username.

Политика тестирования RCE

Тестирование уязвимостей, которые могут приводить к удаленному исполнению кода, должно выполняться в соответствии с данной политикой.

Во время тестирования запрещены любые действия на сервере кроме:

• Выполнения команд ifconfig (ipconfig), hostname, whoami ;
• Чтения содержимого файлов /etc/passwd и /proc/sys/kernel/hostname ("drive:/boot.ini, drive:/install.ini);
• Создания пустого файла в каталоге текущего пользователя.

При необходимости проведения иных действий необходимо предварительно согласовать их с командой безопасности Тинькофф.

Политика тестирования SQL инъекций

Тестирование уязвимостей, которые могут приводить к внедрению команд SQL, должно выполняться в соответствии с данной политикой.

Во время тестирования запрещены любые действия на сервере кроме:

• Получения данных о текущей БД (SELECT database()), ее версии (SELECT @@version), текущего пользователя (SELECT user(), SELECT system_user()) или имени хоста (SELECT @@hostname).
• Получения схемы БД (SELECT table_schema), списка таблиц в ней (SELECT table_name) и имен столбцов в таблицах (SELECT column_name).
• Выполнения математических, конверсионных или логических запросов (включая использование SLEEP) без извлечения данных (кроме тех, что перечислены выше).

При необходимости проведения иных действий необходимо предварительно согласовать их с командой безопасности Тинькофф.

Политика загрузки и чтения файлов

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

Запрещенные действия при загрузке файлов:

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

При получении возможности чтения произвольных файлов на сервере запрещены любые действия кроме чтения таких файлов, как /etc/passwd и /proc/sys/kernel/hostname ([drive:/boot.ini, drive:/install.ini). При необходимости проведения иных действий необходимо предварительно согласовать их с командой безопасности Тинькофф.

Вознаграждения

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

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

Таблица выплат

Определение критичности уязвимости

Мы оставляем за собой право принимать окончательное решение в отношении серьезности найденной уязвимости. После получения отчета мы проводим внутреннее расследование и определяем степень критичности, учитывая множество факторов, в том числе:

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

Благотворительность

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

Примечания

• Почта для связи: bug-hunters@tinkoff.ru.
• Вознаграждение выплачивается только в случае, если команда безопасности Тинькофф посчитает, что все условия правил выполнены и выявленная уязвимость является значимой.
• Размер выплаченной награды является окончательным и не подлежит обсуждению.

FAQ

Как составить хороший отчет?

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

Хороший отчет об уязвимости должен включать в себя следующие составляющие:

• Описание уязвимости;
• Шаги воспроизведения;
• Анализ критичности;
• Рекомендации по устранению.

В отчете также должны содержаться:

• URL уязвимого приложения;
• Тип обнаруженной уязвимости;
• Скриншоты или видеозапись, подтверждающие наличие уязвимости и демонстрирующие шаги воспроизведения;
• Пример форматированного запроса из BurpSuite (или любой другой POC);
• В некоторых случаях куски кода.

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

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

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

Мы не выдаем дополнительные доступы и учетные данные (включая тестовые). Используйте собственные аккаунты для проведения тестирования.

Как и в какие сроки проверяются отчеты?

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

Как осуществляется работа с дубликатами?

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