Our goal at Timeweb is to provide a reliable and convenient service and guarantee the highest level of security for our customers.
Our bug bounty program is an important part of our data and privacy protection strategy aimed at identifying and remediating potential vulnerabilities. We recognize that even the most sophisticated systems can contain vulnerabilities, and we are committed to finding and eliminating them.
We invite the community to join us in looking for potential security issues. Together we can build and maintain a safe and trustworthy space for all users. Join our bug bounty program and help us make our services even more secure.
Vulnerabilities to look for
We are primarily interested in critical server-side vulnerabilities. Still, you're welcome to hunt for any other types of vulnerabilities. If you are unsure whether to contact us about an issue you have found, check if it's on the "Vulnerabilities NOT to look for" list. If it's not on the list, feel free to submit a detailed report.
Examples of vulnerabilities we'll be happy to reward you for (the list is incomplete and is based on the OWASP Top 10):
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 (money withdrawal), removal of restrictions on paid operations and services
Cloud
- Any impact on other users' virtual machines (compromising the confidentiality, integrity, and/or availability)
- Privilege escalation and/or access to maintenance servers
- Other ways to obtain user data
- Other ways to modify user data
- Virtual machine (container) escape, access to the host machine
- Access to the network infrastructure (gray network) with the possibility of negative consequences.
- Logical errors that may occur on a host when creating/deleting a VDS, creating/deleting a backup, or rebooting/switching on/switching off a VDS
Special attention
- Escape from the virtual server to the host system
- Infiltration of a machine with DBaaS
- DBaaS vulnerabilities (vulnerable versions of MySQL, PG, and so on, currently requested from the control panel)
Shared hosting
- Privilege escalation on a hosting server (root access) or obtaining another client's privileges
- Privilege escalation on a provisioning server (root access) and/or access to a provisioning server (non-root access)
Mobile app
Vulnerabilities that affect the server infrastructure by way of mobile application or API exploitation (for example, OWASP Mobile Top 10)
Important: local issues and possible impact on a mobile device are out of scope.
Examples of vulnerabilities included in the scope:
- Bypass of financial tools (money withdrawal), removal of restrictions on paid operations and services
- Errors resulting in horizontal privilege escalation (account hijacking)
- Errors leading to remote code execution on API nodes
SQL injection testing rules
When testing for SQL injection vulnerabilities, researchers must adhere to the following policy. Only the following actions are allowed on the server:
- 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).
Any other actions must be coordinated with the company.
File read and upload rules
When testing for arbitrary file read vulnerabilities and file upload vulnerabilities on the server, researchers must adhere to the following policy. When uploading files, the following actions are prohibited:
- 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 an 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).
- If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read files such as /etc/passwd and /proc/sys/kernel/, hostname (drive:/boot.ini, drive:/install.ini).
Any other actions must be coordinated with the company.
Vulnerabilities NOT to look for
- Any CSRF for https://community.timeweb.com or https://timeweb.com/ru/community
- sentry.timeweb.*
- Bitrix-related issues on timeweb.com
- Apache Guacamole console*.timeweb.ru
- 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
- Vulnerabilities in k8s that have no significant impact on the company's infrastructure
- Any interaction between linked accounts, as it is considered noncritical and is the responsibility of the customer
- Privilege escalation from a secondary account (shared hosting or cloud) to the primary account by any means
- Simplified registration and authorization without CAPTCHA validation, SMS verification, and other best practices
- Reports from security scanners and other automated systems
- Vulnerability reports based solely on software/protocol versions with no credible proof of concept
- A 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 Timeweb products and services
- Session fixation
- Self-XSS
- Scripting in PDF documents
- Hypothetical attacks without proof of their 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
- All types of Hijacking;
- Problems with DMARC/SPF, DNSSEC, or DKIM records
- Missing security headers
- Missing security flag or HttpOnly cookie
- Unvalidated redirects and forwards
- Web Application Firewall (WAF) bypass, or direct access to the server
- HTTP OPTIONS or TRACE methods enabled
- Man-in-the-middle (MITM) attack or interception
- Attacks that require a user to be present online
- Any product features implemented without taking into account best cybersecurity practices, dark cybersecurity patterns, and so on
-DOS/DDOS
Participation rules
By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of these rules may result in forfeiture of rewards.
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 detect a 0-day or 1-day vulnerability for which an official patch was released less than a week ago, the bounty is paid at the discretion of the Timeweb security team and considered on a case-by-case basis.
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 data 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 report must contain the following:
- 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 exploitation, 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 exploitation/
- Brief recommendations for remediation
Please submit a separate report for each discovered vulnerability. If multiple security issues must be exploited to carry out an attack, you can describe them in a single report. In that case, present it clearly in the report and specify the number of discovered vulnerabilities and their class.
HOW TO CREATE AN EFFECTIVE REPORT
To write comprehensive reports for vulnerability research platforms is an important skill for a successful hacker. A few tips:
- Describe the problem: include all the relevant details about the discovered vulnerability, including its type, the specific actions that led to its discovery, and its potential impact on the system.
- Describe steps to reproduce: provide the exact steps that will allow our developers to reproduce the issue. The better they can replicate your actions, the easier it will be to fix the vulnerability.
- Include supporting evidence: include any additional materials that may help us to understand and reproduce the issue, such as screenshots, screen recordings, or code snippets.
- Provide a vulnerability classification: identify the vulnerability class according to a modern vulnerability classification system (for example, OWASP). This will help our team to better understand its potential implications.
- Give recommendations: don't stop at vulnerability detection. Offer practical recommendations on how to fix the problem, for example, suggest ways to improve system security or protect the infrastructure against future attacks.
- Be professional: take the reporting process seriously. Follow ethical and legal guidelines, do not disclose the information you receive to third parties, and cooperate with the development team to help fix the problem.
- Review your work: before you submit your report, make sure it is well-structured and easy to understand. Check your grammar and spelling to ensure your report looks professional.
Vulnerability severity assessment
We reserve the right to make the final decision on the severity of the discovered vulnerability. After receiving the report, we conduct an internal investigation and determine the severity level based on multiple factors, including the following:
- 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
Reward!
We reward external security researchers only for the discovery of previously unknown vulnerabilities, provided that all participation rules are complied with.
All reports are considered on a case-by-case basis with regard to the severity of the discovered vulnerability and the criticality of the affected system.
Information on the reward amount is provided in the table below:
| Vulnerabilities | Reward |
|---|
| Remote code execution (RCE) | up to ₽200,000 |
| SQL injection with access to critical data | up to ₽150,000 |
| SQL injection | up to ₽50,000 |
| Blind SSRF | up to ₽50,000 |
| Server-side vulnerability with disclosure of sensitive information (IDORs) | ₽10,000–₽75,000 |
| Stored XSS | ₽10,000–₽20,000 |
| XSS, except for Self-XSS | ₽5,000–₽10,000 |
| Business logic errors | on a case-by-case basis |
| Other confirmed vulnerabilities | on a case-by-case basis |
Additional information on rewards
We understand that each vulnerability is unique and may have an unexpected impact on security and business operations. The reward amounts listed in the table are based on our general guidelines, but if you identify a particularly serious vulnerability, the reward amount may be significantly increased.
Discovered vulnerabilities that pose a significant risk to our company are eligible for a larger reward, and include the following:
- Remote code execution (RCE) which can take down our servers, destroy data, or disrupt business operations
- SQL-injection which can be used to access, manipulate, or completely delete critical data
Any other scenarios that pose major risks to data, infrastructure, or users
In this case, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.
We appreciate your effort and are willing to reward you fairly for finding vulnerabilities that help us protect our users and our business.
How long does it take to check your report?
Vulnerability reports are reviewed by our internal security team. Response times may vary depending on our workload, but we try our best to process requests within two to three days.
Rules for handling duplicates
We reward only the first submissions (provided the report contains all the necessary information to reproduce the vulnerability exploitation). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our cybersecurity team believes that the information from an earlier report is sufficient to address all reported attack vectors or errors. Your report may be considered a duplicate of a report authored by another researcher or our cybersecurity team.
Vulnerability disclosure policy
You may not share any details on the discovered vulnerabilities without written permission of the Timeweb security team.
Useful information
For general information about our services, follow these links:
Public-api.timeweb.com is the Cloud service API. For information about public-api.timeweb.com:
How to create research accounts
- Sign up using your own mailboxes.
- After you signed up for the products you're researching, send us your test account login(s).
- Provide a link to your Standoff365 profile (your profile must be verified).
- Send us an email with these details to bugbounty@timeweb.ru, and we will credit you with a bonus payment for testing.
Links
Tasks from the testing scope are evaluated to the maximum based on their severity as listed below.
However, some cases may be considered on an individual basis if the detected vulnerability has a significant impact on the infrastructure.на инфраструктуру в целом.