Welcome to Tinkoff Bug Bounty Program

Tinkoff is an online financial ecosystem built around one of the world’s largest online banks. We are open for collaboration with external researchers in order to improve the security of our products. If you have any information related to vulnerabilities in our services, please submit a report in accordance with the guidelines below.

Accepted languages:
🇬🇧 English
🇷🇺 Russian

Important:
To test most of our applications you need a Tinkoff bank account. You can open it only if you are a Russian resident or a foreigner legally residing in the country.

Table of Contents

• Scope
  1. Main Targets
  2. In Scope Vulnerabilities
  3. Out of Scope Vulnerabilities
  4. No Bounty Vulnerabilities
• Rules of Engagement
  1. Common Rules
  2. Testing Rules
  3. Disclosure Policy
  4. Traffic Identification Policy
  5. RCE Testing Policy
  6. SQL Injection Testing Policy
  7. File Read and File Upload Testing Policy
• Rewards
  1. Payout Table
  2. Severity Guidelines
  3. Charity
  4. Notes
• FAQ
  1. How to create a good report?
  2. Do you provide any credentials for testing?
  3. How are bug reports examined?
  4. How do you handle duplicates?

Scope

Scope of our Bug Bounty Program is limited to the following domains – *.tinkoff.ru, *.tcsbank.ru, *.tinkoffinsurance.ru. But only Main Targets eligible for maximum rewards. Other web resources and mobile applications have significantly reduced or zero payout ratio.

Main Targets

Main domains and mobile apps of the following services:

• Tinkoff Bank
• Tinkoff Investments
• Tinkoff Business
• Tinkoff Mobile
• Tinkoff ID
• Tinkoff Messenger
• Tinkoff Insurance
• Tinkoff Travel
• Tinkoff Work
• Tinkoff Payments

Please note that secondary domains of the above services are not in Main Targets.

In Scope Vulnerabilities

We are primarily interested in critical server-side vulnerabilities. Other types of security issues are also welcome. If in doubt whether to contact us regarding a problem that you detected, firstly try to look it up in the Out of Scope Vulnerabilities. If it is not there, feel free to send us a report with a detailed description. You can find more information about the best way to report a vulnerability in the FAQ.

Accepted, in scope vulnerabilities include, but are not limited to:

• RCE
• Injections (e.g. SQL Injection or XML Injection)
• LFR/LFI/RFI
• SSRF
• Memory leaks
• Business logic vulnerabilities
• IDOR
• Authorization bypass
• Disclosure of sensitive or personally identifiable information
• Account takeover
• Incorrect authentication or authorization
• XSS and CSRF (affecting sensitive data)

Out of Scope Vulnerabilities

The following issues are considered out of scope:

• Vulnerabilities in services outside the Tinkoff ecosystem
• Fraudulent schemes, abuse of legitimate functionality (we recommend sending such messages to the support chat, there is no reward for such reports)
• Non-security issues
• Information about potential DDOS attacks
• Information about IP addresses, DNS entries, and open ports
• Phishing and other social engineering techniques
• Scanner output or scanner-generated reports, including any automated or active exploit tool
• Information about publicly accessible login panels
• Clickjacking
• Disclosure of public user information
• Information about risks of short OTP code
• Rounding errors in money transfers (there are limits imposed on such transactions)
• Bypass detecting root or jailbreak
• Ability to reverse-engineer mobile applications, lack of binary protection

No Bounty Vulnerabilities

These issues are eligible for submission, but not eligible for bounty or any award:

• Self-XSS, XSS specific to non-common or outdated browsers, Flash-based XSS
• CSRF and XSS without security impact
• Missing security best practices* (e.g. missing cookie flags, missing security HTTP headers)
• CORS misconfiguration*
• Using outdated or potentially vulnerable third party software*
• Attacks involving payment fraud or theft
• Spamming with OTP, emails and etc
• Denial of Service (DOS) attacks*
• Missing best practices in SSL/TLS configuration*
• Disclosure of information that such username, email or phone exists in the system
• Full Path Disclosure
• Disclosure of technical or non-sensitive information* (e.g. software version, detailed error messages)
• Open Redirect without demonstration an additional security impact (e.g. ability to steal authentication token)
• Content spoofing
• Tabnabbing
• Vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls
• Vulnerabilities requiring a rooted, jailbroken or otherwise modified device
• Attacks requiring MITM or physical access to a user’s device
• Unlikely or theoretical attacks without proof of exploitability

* — without showing an attack vector and evidence of security impact

Rules of Engagement

By submitting reports or otherwise participating in our Bug Bounty Program, you agree that you have read and will follow the Rules of Engagement section of this Policy. Violation of any of these rules can result in ineligibility for a bounty and/or removal from the program.

Common Rules

• The program's scope is limited to technical vulnerabilities in the company's web services or mobile apps.To report non-security issues, please contact customer support.
• 0-day/1-day vulnerabilities may be considered as a duplicate within one week after vulnerability details publication. Reward decision is made by Tinkoff security team for each report individually.

Testing Rules

• Use your own accounts, phone numbers, etc to conduct your research or user you are authorized by. Do not try to gain access to others' accounts or any confidential information.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
• Social engineering, phishing, DOS attacks, physical attacks and other activity that would be disruptive, damaging or harmful to Tinkoff, its brands or its users are strictly prohibited.
• When testing use the minimal possible POC (Proof of Concept) to validate a vulnerability. In cases when it may impact systems or users, ask permission first. Further exploitation of vulnerabilities is strictly prohibited.
• Limit any automated scanning to 5 requests per second.

Disclosure Policy

• It is prohibited to disclose vulnerabilities or share any details without a written consent of our security team.
• We reserve the right to deny any request for public disclosure.

Traffic Identification Policy

There is a possibility that the traffic generated by security researches will be classified as malicious. In order to avoid any problems related to this fact, please include the following HTTP header to all your traffic – X-Bug-Bounty: username.

RCE Testing Policy

Testing vulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.

Allowed actions when conducting RCE attempts (another actions are prohibited):

• Executing ifconfig (ipconfig), hostname and whoami
• Reading content of the /etc/passwd file or /proc/sys/kernel/hostname file (drive:/boot.ini, drive:/install.ini)
• Creating an empty file in the current user folder

If you need to perform any other action, you need to first get them approved by the Tinkoff security team.

SQL Injection Testing Policy

Testing vulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.

Allowed actions when conducting SQLI attempts (another actions are prohibited):

• Executing SELECT queries such as database(), @@version, user(), system_user(), @@hostname
• Listing databases names from schema, listing columns, table names
• Executing mathematical, conversion or logical queries (including SLEEP) without extracting data (except those listed above)

If you need to perform any other action, you need to first get them approved by the Tinkoff security team.

File Read and File Upload Testing Policy

Testing vulnerabilities which may lead to arbitrary uploading or reading files are subjected to these rules.

Prohibited actions when conducting file uploading attempts:

• Altering, modifying, deleting, replacing any files on the server (including system files), except files which is owned by you or user you are authorized by
• Uploading files which can cause Denial of Service (e.g. over-sized files)
• Uploading malicious files (such as malware or spyware)

It is prohibited to read any files except /etc/passwd or /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini) when conducting file reading attempts. If you need to read any other file, you need to first get them approved by the Tinkoff security team.

Rewards

You may be eligible to receive a monetary reward if:

• You are the first person to submit the vulnerability
• That vulnerability is determined to by a valid security issue by our security team
• You have complied with all Rules of Engagement

All reports are reviewed according to severity of the vulnerability and criticality of the affected system on a case-by-case basis. Maximum reward amounts are provided in the table below.

Payout Table

Severity Guidelines

We reserve our right to make a final decision about severity of a particular vulnerability. After receiving the report we carry out an internal analysis of the problem and determine their severity and impact based on many factors including:

• Opportunity
• Easy of discovery and exploitation
• User interaction
• Loss of integrity, availability and confidentiality
• Financial and reputation damage
• Affected users

Charity

You may prefer the reward go toward helping others who really need it. Tinkoff will give a five-fold increase to your reward and forward it to one of the trusted foundations listed in the Charity Section at your choice! All rewards unclaimed within a year's time will be automatically donated to trusted foundation.

Notes

• Contact email: bug-hunters@tinkoff.ru.
• Reward is granted if only Tinkoff security team believes that all Rules of Engagement have been observed and founded vulnerability is valued.
• The amount of the award paid is final and non-negotiable.
• All payments are made through HackerOne.

FAQ

How to create a good report?

Submit one vulnerability per report. The exception are cases where vulnerabilities are either interconnected or can be combined into a chain to increate impact.

A good report should include:

• Description of the vulnerability
• Steps to reproduce
• Severity analysis
• Fix recommendations

The report should also contain:

• List of URLs and affected parameters
• Vulnerability type
• Proof of exploitability (e.g. screenshot, video)
• Proof of Concept code

Failure to observe the minimal requirements may lead to a decrease of the reward amount. If our security team cannot reproduce and verify an issue, the report will not be eligible for a reward.
All supporting evidence and other attachments must be stored only within the report you submit. Do not host any files on external services.

Do you provide any credentials for testing?

We provide no additional access or account credentials (including for testing purposes). Please use your own accounts to perform your testing.

How are bug reports examined?

Vulnerability reports are examined by our security team. Response time depends on our workload, but we aim to respond to incoming submissions within two weeks.

How do you handle duplicates?

We only reward the first report that was received (provided that it can be fully reproduced). Any further reports about the same vulnerability will be treated as a duplicate. Reports containing different exploitation vectors for same or similar bugs may be considered duplicating if our security team believes information provided in one of such reports is enough to fix all vectors or bugs reported. Report can be either a duplicate of another researcher's report or a duplicate of the problem internally tracked by our security team.