Program rules

Supported languages

• English
• Russian

Contents

• Vulnerabilities to look for
• Vulnerabilities NOT to look for
• Participation rules
• Rewards
• Useful information
• How to register test accounts

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

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

Vulnerabilities to look for

General

• Remote code execution (RCE)
• Injections (such as SQL and XML injections)
• LFR/LFI/RFI
• Blind SSRF
• Business logic vulnerabilities
• IDOR
• Access control vulnerabilities
• Sensitive information disclosure
• Account hijacking
• XSS and CSRF that affect sensitive data
• Bypass of financial tools (fund withdrawal), removal of restrictions on chargeable operations and services

Security flaws to pay special attention to

• Privilege escalation on a hosting server (root access) or obtaining of another client's privileges
• Privilege escalation on a maintenance server (root access) and/or access to a maintenance server (non-root access)

• Bypass of financial tools (fund withdrawal), removal of restrictions on chargeable operations and services
• Errors resulting in horizontal privilege escalation (account hijacking)
• Errors leading to remote code execution on API nodes

Vulnerabilities NOT to look for

XSS, CSRF, And UI Attacks

• Self-XSS;
• Any XSS that can only be executed within a single account, regardless of the number of users in that account;
• Logout CSRF;
• Clickjacking and framing without demonstrated standalone impact;
• Scripting in PDF documents;

Information Disclosure Without Significant Impact

• Disclosure of non-confidential information, such as product versions, public API methods, public/demo/test API tokens without access to protected data, operations, or privileges;
• Disclosure of public information about a user or community, such as a nickname;
• Disclosure of internal diagnostic data, including stack traces, internal hostnames, IP addresses, service names, paths, and error messages, without demonstrated standalone impact;
• Disclosure of EXIF metadata in images;
• Vulnerabilities that allow discovery of an IP address without other identifying customer information, such as full name or login;
• Disclosure of public API keys/tokens without access to protected data, operations, privileges, or internal systems;

Authentication, Authorization, And Accounts

• Simplified registration or authentication without CAPTCHA, SMS, or other best-practice checks;
• Authentication or authorization weaknesses that do not allow access to other users' data, operations, or privileges and do not lead to further exploitation;
• Vulnerabilities related to the attribute-based access control model (IAM), including restricted tokens and additional account users, unless impact outside the corresponding account or tenant context is demonstrated;
• Privilege escalation from a secondary shared hosting or Cloud account to the primary account and vice versa by any means, unless access to data, operations, or privileges of another independent customer or Timeweb infrastructure is demonstrated;
• Session fixation without confirmed account takeover or other standalone impact;
• Enumeration of system users, logins, email addresses, or other identifiers without access to protected data, operations, or privileges;
• Any issues related to brute force;

Configuration, Hardening, And Best Practices

• Incorrect configuration, absence, or incomplete implementation of security controls, such as CORS, CSP, CSRF, SameSite, X-Frame-Options, and similar controls, without demonstrated standalone impact, such as access to protected data, performing actions on behalf of a user, or authorization bypass;
• Missing security headers;
• Missing Secure or HttpOnly cookie flags without demonstrated standalone impact;
• Product features implemented without security best practices, security dark patterns, and similar findings without demonstrated standalone impact;
• Issues with DMARC, SPF, DNSSEC, or DKIM records;
• Enabled HTTP OPTIONS or TRACE methods without demonstrated practical impact;

SSRF, Network Reachability, And Interception

• Blind SSRF or internal network reachability without safely demonstrated impact, for example via an approved test endpoint or a provided internal test host;
• MitM, interception, or attacks requiring control of the victim's network or physical presence in the network;
• WAF bypass or direct server access without demonstrated practical impact;

Redirect, Domain, And Link Hijacking

• Invalid redirects and open redirects, unless the issue affects service security, for example by allowing theft of a user authorization token;
• Broken Link Hijacking and Domain Hijacking;
• IDN homograph attacks;

DoS, Abuse, And Spam

• DoS/DDoS;
• Ability to send a large number of messages;
• Ability to send spam or malware files, for example spam emails related to registration or password recovery;
• Abuse of public forms and endpoints intended for anonymous user input, unless access to other users' data, accounts, payment operations, or other standalone security impact is demonstrated;

Race Conditions And Input Validation

• Race conditions without confirmed violation of authorization, billing, quotas, data access, or another significant security/business invariant;
• Input validation issues in any form without a demonstrated real vulnerability;

Reports Without Sufficient Proof

• Reports from security scanners or other automated systems without manual validation and confirmed impact;
• Reports based solely on software or protocol versions without a reliable proof of concept;
• Theoretical attacks without proof of practical exploitability;

Scope And Product Exclusions

• Vulnerabilities in partner services or products that do not directly affect the security of Timeweb products and services;
• Any vulnerabilities in the old file manager on VH, including the legacy fileman / AJAX version;
• Attacks requiring full access to the user's device, page, or browser profile;

Participation rules

General rules

• The scope of the bug bounty program is limited to technical vulnerabilities in the company's services. If you encounter problems that have nothing to do with security, please contact customer support.
• If you discover a 0-day or 1-day vulnerability for which an official patch was released less than a week ago, your report will be considered on an individual basis and may be awarded with a bounty at the discretion of the TimewebTech security team.

Testing rules

• For testing, you can use only your own accounts, accounts of users who have explicitly given their consent, or accounts provided for testing with bonus rates. Do not attempt to access other people's accounts or any sensitive information.
• While searching for vulnerabilities, avoid compromising the confidentiality, integrity, and availability of information in our services.
• Any activity that could harm the company's applications, infrastructure, customers, or partners is strictly prohibited. Examples of prohibited activities include social engineering, phishing, denial-of-service attacks, and physical attacks on the infrastructure.
• To confirm a vulnerability, use the smallest possible proof of concept (POC). If this could impact other users or the system's performance, please contact us to get permission. Further exploitation of vulnerabilities is strictly prohibited.

Report requirements

• A full description of the discovered vulnerability
• A description of the impact on user and/or system security
• The steps required to reproduce the vulnerability, including the following (if possible):
  ◦ Screenshots
  ◦ Videos
  ◦ Requests/responses
  ◦ Code of the exploit used
  ◦ Date and time of request execution
• IDs of accounts used in testing
• Other materials required to reproduce the vulnerability
• Brief recommendations for remediation

Vulnerability severity assessment

• Privileges required to conduct the attack
• Difficulty of discovery and exploitation
• Need for user interaction
• Impact on the integrity, availability, and confidentiality of the affected data
• Potential business and reputational risks
• Number of affected users

Rewards

Reward amounts

Additional information on rewards

• Remote code execution (RCE) that can take down our servers, destroy data, or disrupt business operations
• SQL-injections that can be used to access, manipulate, or completely delete critical data
• Any other scenarios that pose major risks to data, infrastructure, or users

How long does it take to check your report?

Rules for handling duplicates

Vulnerability disclosure policy

Useful information

• https://timeweb.tech/docs/
• For testing Blind SSRF and internal network access capabilities, you can send requests to 192.168.4.72:8000

How to register test accounts

1. Sign up for the products to test using your own mailboxes.
2. After signing up, tell us your test account login (or logins). 
3. Provide a link to your Standoff 365 profile (your profile must be verified).
4. Send us an email with these details to bugbounty@timeweb.tech, and we will credit you with a bonus payment for testing.

Link to the service