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
• Flawed authentication/authorization
• 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 that can only be performed from a single account (regardless of the number of account users)
• Disclosure of non-confidential information, such as product versions
• Disclosure of public user information, such as usernames
• K8s vulnerabilities that have no significant impact on the company's infrastructure
• Any interaction between linked accounts (as it is considered noncritical and lies within the responsibility of the customer)
• Privilege escalation from a secondary shared hosting or cloud account to the primary account by any means
• Simplified registration and authorization without CAPTCHA validation, SMS verification, or other best practices
• Reports from security scanners and other automated systems
• Vulnerability reports based solely on software or protocol versions with no credible proof of concept
• Lack of security mechanisms or non-compliance with recommendations (for example, the absence of a CSRF token) without mentioning specific negative consequences
• Logout CSRF
• Blind SSRF with no ability to scan or send requests to the internal infrastructure
• Framing
• IDN homograph attacks
• Disclosure of public information about a user or a community
• Attacks that rely on full access to a user device or page, or browser profile
• Vulnerabilities in partner services and products that do not directly affect the security of TimewebTech products and services
• Session fixation
• Self-XSS
• Scripting in PDF documents
• Hypothetical attacks without proof of feasibility
• Any issues related to bruteforcing
• Problems associated with validation of input data in any form without an actual vulnerability
• Any possibilities of user enumeration, login enumeration, and so on
• Clickjacking
• Any types of hijacking
• Missing security headers
• Missing security flag or HttpOnly cookie
• Unvalidated redirects and forwards
• Open redirects, unless they compromise the security of the service (for example, by allowing authorization token theft)
• Web application firewall (WAF) bypass, or direct access to the server
• HTTP OPTIONS or TRACE methods enabled
• Man-in-the-middle (MITM) attacks or interception
• Attacks that require a user to be present online
• Any product features implemented without taking into account best cybersecurity practices, dark patterns, and so on
• DoS/DDoS
• Possibility of sending a large number of messages
• Possibility of sending spam or malware files (for example, spam registration or password recovery emails)
• Exposure of private API methods or tokens
• Exposure of EXIF image metadata
• Vulnerabilities that allow disclosure of an IP address without revealing other identifying information about the client (such as the client's full name or login)
• Possible vulnerabilities in the virtual hosting IDE (https://.timeweb./ide/)

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

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