Welcome to the Tochka Bank's bug bounty program!

Scope

Bounty policy

Vulnerabilities to look for

General rules

• By participating in our program, you confirm that you have read and agree to these Rules. Violations may result in disqualification from receiving a bounty.
• The program scope is limited to technical security vulnerabilities in our services.
• If you identify multiple security issues in Tochka services, submit a separate report for each vulnerability.
• If we receive multiple reports for the same vulnerability, only the first report received is eligible for a bounty (provided the issue is fully reproducible).
• If multiple vulnerabilities share the same underlying root cause, we will treat them as a single vulnerability for bounty purposes.
• Bounty eligibility and bounty amount may depend on severity, novelty, likelihood of exploitation, the affected environment, and/or other factors.
• Vulnerability types eligible for bounties are listed in the "Bounty policy" section.
• The bounty ranges listed in the Program description are for reference only.
• Reports submitted by current or former employees of the Tochka Group (if the former employee's employment ended within the past year) are accepted but are not eligible for a bounty.
• Tochka commits not to make unfounded accusations against researchers in connection with participation in the Program.

Testing rules

• Always include the HTTP header X-Bug-Bounty: <your platform username> with your requests.
• Avoid actions that might result in privacy violations, data loss or destruction, and any interruption or degradation of our services.
• Automated scanning must be limited to 10 requests per second per target host, summed across all tools and concurrent threads.
• We do not provide any accounts for testing purposes.
• Use the minimal proof of concept (PoC) necessary to demonstrate the issue. If your activity may affect users or service availability, please contact us to coordinate next steps. Any further exploitation is prohibited.

Not accepted and not reviewed

• Reports about missing rate limiting with no demonstrated impact on user or system security (such reports are treated as informational), for example: email and SMS campaigns, lead generation, and more.
• Reports generated by security scanners and other automated tools.
• Information about IP addresses, DNS records, and open ports.
• Reports of issues and vulnerabilities that are based only on the product version in use, without a working exploit or clear exploitation scenario.
• Reports of vulnerabilities whose exploitation is prevented by security tools, unless you demonstrate a bypass of those tools (for example, a WAF).
• Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
• Self-XSS and other vulnerabilities that do not directly affect users or application data.
• Vulnerabilities that require outdated browser versions (released 6 months or more before report submission) or browsers that are no longer supported.
• Reports of cross-origin resource sharing (CORS) misconfigurations without demonstrating exploitation.
• User enumeration reports that only confirm whether a specific username, email address, or phone number exists in the system.
• Disclosure of sensitive user information via third-party resources not controlled by Tochka (for example, data collected by spyware or content posted by users themselves).
• DoS attacks and reports of potential denial of service.
• Tabnabbing.
• Clickjacking.
• Logout CSRF.
• Reports of Content Security Policy (CSP) issues for domains without CSP and domain policies with 'unsafe-eval' and/or 'unsafe-inline'.
• Attacks that rely on full access to a local account or browser profile.
• Vulnerabilities that require a complex or unlikely user interaction scenario.
• Missing best practices in DNS and email configuration (DKIM, DMARC, SPF, or TXT).
• Broken or outdated links to social media pages and similar resources.
• Ability to perform an action unavailable via the user interface without identifiable security risks.
• Unlimited ability to create user accounts.
• User enumeration.
• Disclosure of publicly available user information.
• Lack of notifications about important user actions.
• Reports related to the security of Tochka Bank mobile applications.
• Issues not related to security (to report these issues, please email us at bank@tochka.com).
• Reports on fraudulent schemes or abuse of legitimate functionality.
• Reports of missing protection mechanisms or best practices without demonstrating real security impact for the user or system. (Such reports will be considered as informative.) For example: missing HTTP security headers (CSP, HSTS, and so on), cookie security flags (HttpOnly, Secure, and so on), anti-CSRF tokens, or SSL certificates.

Public vulnerability disclosure

Prohibited activities

• Don't access another user's data without their consent, don't modify or delete it, and don't disclose any confidential information obtained during testing or PoC validation. Deliberate access to sensitive data is prohibited and may be deemed illegal.
• Don't interfere with other users' accounts without their permission.
• Don't use any discovered vulnerability for personal benefit.
• Don't use vulnerability testing tools that automatically generate high volumes of traffic and could lead to resource exhaustion.
• Don't conduct attacks that could compromise the integrity or availability of our services (for example, DoS or brute-force attacks), and don't attempt to exploit resource exhaustion vulnerabilities. Please report the issue to the Tochka team, and we will validate it in a test environment.
• Don't conduct physical attacks against our employees, data centers, or offices.
• Don't use social engineering techniques (including phishing and vishing), and don't send spam to our customers, partners, or employees.
• Don't probe, scan, or enumerate the underlying server infrastructure hosting our web applications.
• Don't disclose details of any vulnerability you discover.

RCE testing rules

• Execute the ifconfig (ipconfig), hostname, whoami, and id commands.
• Read the contents of the /etc/passwd and /proc/sys/kernel/hostname files (drive:/boot.ini, drive:/install.ini).
• Use the echo command to write to a file located at "/tmp/" or in the current user directory, read the file, and delete it immediately after the vulnerability is confirmed.

SQL injection testing rules

• Get information about the current database (SELECT database()), its version (SELECT @@version), the current user (SELECT user() or SELECT system_user()), or hostname (SELECT @@hostname).
• Get the database schema (SELECT table_schema), list of tables (SELECT table_name), and table column names (SELECT column_name).
• Perform mathematical, conversion, or logical queries (including using SLEEP) without retrieving data (excluding those mentioned above).

File read and upload rules

• Don't change, modify, delete, or replace any files on the server (including system files) except for files associated with your own account or the account of a user who gave explicit consent for such actions.
• Don't upload files that could cause a denial of service (for instance, large files).
• Don't upload malicious files, including malware or spyware.

Report content guidelines

• Vulnerability description
• Step-by-step reproduction instructions
• Severity assessment
• Remediation recommendations

• URL of the affected application
• Vulnerability type
• Screenshots or video recordings demonstrating the vulnerability and the steps to exploit it
• An example of a properly formatted request from Burp Suite (or any other PoC)

Vulnerability severity assessment

• How difficult the issue is to discover and exploit
• The level of privileges required to carry out the attack
• Whether user interaction is required
• Impact on the confidentiality, integrity, and availability of affected data
• The number of users affected

Duplicate reports