# Welcome to T-Bank Bug Bounty Program

T-Bank 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 T-Bank 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 – `*.tbank.ru`, `*.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:

- T-Bank
- T-Investments
- T-Business
- T-Mobile
- T-ID
- T-Messenger
- T-Insurance
- T-Travel
- T-Work
- T-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 T-Bank 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 TT-Bank 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 T-Bank, 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 T-Bank 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 T-Bank 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 T-Bank 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    |    Critical   |    High    |    Medium    |    Low    |
| ------------- | ------------- | ------------- | ------------- | ------------- |
|    Maximum reward    |    $10000    |     $4000    |    $500    |    $100    |

### 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. T-Bank will give a five-fold increase to your reward and forward it to one of the trusted foundations listed in the [Charity Section](https://www.tinkoff.ru/payments/categories/blagotvoritelnost/) 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 T-Bank 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.

T-Bank

Online financial ecosystem built around one of the world’s largest online banks

https://tbank.ru

Online financial ecosystem built around one of the world’s largest online banks.

# Welcome to T-Bank's Rule-Bounty!

Rule-Bounty is an additional reward program for researchers who help us improve code security by creating unique rules for Semgrep Community Edition. For each new rule that meets the requirements below, we pay the same as the main bug bounty program.

# ≡ Table of Contents

1. [Program Objective](#head1)
2. [Scope](#head2)
3. [Rule Requirements](#head3)
4. [What Not to Submit](#head4)
5. [Verification Process and Duplicates](#head5)
6. [Payout Table](#head6)
7. [Determining Rule Criticality](#head7)
8. [Rules of Participation](#head8)
9. [FAQ](#head9)
10. [Example of a Well-Formed Rule](#head10)
11. [Contact Us](#head11)

## <a name="head1"></a>1. Program Objective

We want to create **unique, practically useful rules for Semgrep** that find vulnerabilities in T-Bank repositories and improve the quality of our internal rule base. The higher the practical value and impact of the rule, the higher the reward.

## 2. <a name="head2"></a>Scope

- Explore popular languages ​​and frameworks (Java/Kotlin/Scala, C#, Go, Python, JavaScript/TypeScript).
- We will validate the rules on an internal sample of T-Bank repositories.

## 3. <a name="head3"></a>Rule Requirements

| # | Requirement | Details |
| - | ---------- | ----------- |
| 1 | Semgrep Community Edition | Use Semgrep CE syntax; features available only in the Enterprise edition are prohibited. |
| 2 | Uniqueness | The rule must not be published in the Semgrep Registry, GitHub, blogs, articles, reports, chats, etc. |
| 3 | CWE | Specify the relevant CWE identifier (e.g., CWE-89: SQL Injection). |
| 4 | Full metadata | Required fields: id, message, severity, languages, metadata.cwe, metadata.category, metadata.confidence, metadata.likelihood, metadata.impact |
| 5 | Snippet | Minimal example code that triggers the rule (Semgrep unit test). |
| 6 | Impact description | Briefly: what the rule detects, what the threat is caused by the remaining vulnerability. |

### Submission format
Submit the YAML file of the rule + snippet (.yml and .txt/.py/…) in a single archive. Describe the logic in the report and indicate how to test it.

## 4. <a name="head4"></a>What not to send

- Duplicate rules of public rules.
- Linter-level rules: code style, cosmetics, dead code without impacting security.
- Templates requiring third-party Semgrep Enterprise plugins.
- Catch-all rules with a large number of false positives.
- Rules without CWE, without a snippet, or with incomplete metadata.
- Info-level rules (Stack Trace, TLS/SSL, CORS, etc.)

## 5. <a name="head5"></a>Verification process and duplicates

1. **Acceptance** - automatic and manual format and condition checking. *If necessary, we can return the rule to the author for revision*.
2. **Uniqueness check**:
- If the rule is found in public sources, the report is closed **without payment, indicating the original source**. - If we already have a similar rule, we send proof, and the report is closed **without payment**.
3. **Impact Validation** - We test the rule on our repositories. For this, we select a scope that matches the rule stack on which the submitted rule is executed. After testing, we validate the results, looking at the number of triggers and the False Positive percentage. *If necessary, we can return the rule to the author for revision*.
4. **Severity Rating** - See the table below.
5. **Payment / Rejection**

## 6. <a name="head6"></a>Payout Table

| Criticality | Critical | High | Medium | Low |
| ----------- | -------- | ------- | ------ | ------ |
| Maximum payout amount, ₽ | 1,000,000 | 400,000 | 50,000 | 10,000 |

> The amount may be reduced if the rule yields a lot of FP, covers a narrow edge case, or is easily bypassed.

## 7. <a name="head7"></a>Determining rule criticality

Key factors:
- ease of use
- potential scale of damage
- number of affected systems.
We evaluate not only the correctness of the rule, but also its **practical usefulness** for T-Bank's code. If the rule fails to produce results on our repositories, it is not eligible for payment.

## 8. <a name="head8"></a>Participation rules (briefly)

- One report - one rule.
- Do not disclose the rule until we respond.
- Only custom rules are allowed.

## 9. <a name="head9"></a>FAQ

### How and when are reports reviewed?

Reports with rules are reviewed by our internal security team. Response time depends on workload, but we strive to process requests within 1 month.
Reports with the "Insufficient information from the hacker" status **without activity for a month** are closed at the discretion of the security team.

### Can small patterns be combined into a single rule?

Yes, if they are logically related and improve accuracy.

## 10. <a name="head10"></a>Example of a well-formatted rule

<details> 
  <summary>[Rule] C# Validate Issuer Signing Key Set To False (*Кликабельно*)</summary>

```
rules:
  - id: validateissuersigningkey-set-to-false
    pattern-either:
      - pattern: |
          ValidateIssuerSigningKey = false
      - pattern: |
          $OPTIONS.ValidateIssuerSigningKey = false
      - pattern: |
          bool $PARAM = false;
          ...
          <... ValidateIssuerSigningKey = $PARAM ...>
      - pattern: |
          bool $VAL = false;
          ...
          <... $OPTIONS.ValidateIssuerSigningKey = $VAL ...>
    metadata:
      category: security
      cwe: "CWE-347: Improper Verification of Cryptographic Signature"
      author: bug-hunters@tinkoff.ru
      confidence: HIGH
      likelihood: HIGH
      impact: HIGH
      subcategory:
        - vuln
    message: Accepting unsigned security tokens as valid security tokens allows an
      attacker to remove its signature and potentially forge an identity. As a
      fix, set ValidateIssuerSigningKey to be true.
    languages:
      - csharp
    severity: ERROR
```

</details>

<details>
  <summary>[Snippet] Validate Issuer Signing Key Set To False (*Кликабельно*)</summary>

```csharp
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
            {

                options.TokenValidationParameters = new TokenValidationParameters
                {
                    // ruleid: validateissuersigningkey-set-to-false
                    ValidateIssuerSigningKey = false,
                    RequireSignedTokens = false,
                    ValidateIssuer = false,
                    ValidateAudience = false
                };
            });

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
            {
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    // ok: validateissuersigningkey-set-to-false
                    RequireSignedTokens = true,
                    ValidateIssuer = false,
                    ValidateAudience = false
                };
            });
```

</details>

## 11. <a name="head11"></a>Contacts

[bug-hunters@tinkoff.ru](mailto:bug-hunters@tinkoff.ru) - any questions about our Bug-Bounty program.

Т-Банк Rule-Bounty

Rule-Bounty - an additional bounty program for researchers who help us improve code security by creating unique rules for Semgrep Community Edition. For each new rule that meets the requirements below, we pay the same as the main bug bounty program.

Programs