# 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

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 or arbitrary file upload vulnerabilities on the server, researchers must adhere to the following policy.

Actions prohibited during file upload testing include the following:

- 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).

If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read the /etc/ufw/user6.rules file. Any other actions must be coordinated with the company.

### 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 are listed below (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 (fund withdrawal), removal of restrictions on chargeable operations and services
- Any impact on other users' virtual machines (compromise of their 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/starting/stopping a VDS

##### Security flaws to pay special attention to

- Escape from the virtual server to the host system
- Infiltration of a DBaaS machine
- DBaaS vulnerabilities (vulnerable versions of MySQL, PG, and so on, currently requested from the control panel)

Examples of vulnerabilities included in the scope:

- 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

Out-of-scope submissions include the following:

- Possible Apache Guacamole vulnerabilities within 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
- Any information obtained from public buckets (s3.timeweb.cloud) through any means
- K8s vulnerabilities that have no significant impact on the company's infrastructure
- Privilege escalation from a secondary shared hosting or cloud account to the primary account (and vice versa) by any means
- IAM vulnerabilities: tokens, roles;
- 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 Timeweb Cloud 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
- Broken Link Hijacking, Domain Hijacking
- Problems with DMARC/SPF, DNSSEC, or DKIM records
- Missing security headers
- Missing security flag or HttpOnly cookie
- 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
- Possible vulnerabilities within sentry.timeweb.*
- 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)
----------

### Participation rules

By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of any 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 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 Timeweb Cloud 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 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, 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
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

### Rewards
---
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. 

---

##### Reward amounts

| 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 (IDOR) | ₽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 severe vulnerability, the reward amount may be significantly increased.

Discovered vulnerabilities that pose a significant risk to our company and are eligible for a larger reward include the following:

- **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

In such cases, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.

We appreciate your efforts and are willing to reward you fairly for finding vulnerabilities, which helps 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). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our security 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 security team.

#### Vulnerability disclosure policy

You may not share any details of the vulnerabilities you discover without written permission of the Timeweb Cloud security team.

----------

### Useful information

For general information about our services, go to:

- https://timeweb.com/ru/docs/
- https://timeweb.cloud/faq

Public-api.timeweb.com is the Cloud service API. For information about public-api.timeweb.com, go to:

- https://timeweb.cloud/api-docs

To test for blind SSRF with access to the intranet, 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.cloud, and we will credit you with a bonus payment for testing.
##### Link to the service

- (Cloud) https://timeweb.cloud/?auth=registrationAccount

**Issues found within the testing scope are evaluated based on their severity, to the maximum extent applicable. 
However, some cases may be considered on an individual basis if the discovered vulnerability has a significant impact on the whole infrastructure.**

TimewebCloud

Timeweb Cloud is a cloud platform designed for businesses and people to build, scale, and manage IT infrastructures worldwide. Our company is included in the Unified Register of Russian Software and ranks among the top 6 largest cloud providers in Russia.

https://timeweb.cloud/

Timeweb – облачная платформа для бизнеса и частных лиц, позволяющая создавать, масштабировать и управлять IT-инфраструктурой по всему миру. Компания включена в реестр отечественного ПО и входит в топ-5 крупнейших облачных провайдеров России. 

https://timeweb.cloud/ - Облачная IT-инфраструктура для бизнеса, стартапов и независимых разработчиков. 
https://timeweb.com/ru/ - shared-хостинг 
https://mail.timeweb.com/login - Сервис почты 
https://craftum.com/ - Конструктор сайтов 
https://cheapsender.email/ - Сервис рассылок

Timeweb

# 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

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 or arbitrary file upload vulnerabilities on the server, researchers must adhere to the following policy.

Actions prohibited during file upload testing include the following:

- 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).

If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read the /etc/ufw/user6.rules file. Any other actions must be coordinated with the company.

### 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 are listed below (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 (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)

Examples of vulnerabilities included in the scope:

- 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

Out-of-scope submissions include the following:

- 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

By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of any 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 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 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, 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
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

### Rewards
---
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. 

---

##### Reward amounts

| 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 (IDOR) | ₽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 severe vulnerability, the reward amount may be significantly increased.

Discovered vulnerabilities that pose a significant risk to our company and are eligible for a larger reward include the following:

- **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

In such cases, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.

We appreciate your efforts and are willing to reward you fairly for finding vulnerabilities, which helps 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). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our security 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 security team.

#### Vulnerability disclosure policy

You may not share any details of the vulnerabilities you discover without written permission of the TimewebTech security team.

----------
### Useful information

For general information about our services, go to:
https://timeweb.tech/docs/

----------

### 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

https://my.timeweb.tech/login

**Issues found within the testing scope are evaluated based on their severity, to the maximum extent applicable. 
However, some cases may be considered on an individual basis if the discovered vulnerability has a significant impact on the whole infrastructure.**

TimewebTech

TIMEWEB Platform Website Management Panel ("Platforma TIMEWEB panel upravleniya saytami") is software designed to host user web projects on timeweb.tech servers, ensuring their online availability.

https://timeweb.tech/

# 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

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 or arbitrary file upload vulnerabilities on the server, researchers must adhere to the following policy.

Actions prohibited during file upload testing include the following:

- 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).

If an arbitrary file read vulnerability is discovered on the server, the researcher is only allowed to read the /etc/ufw/user6.rules file. Any other actions must be coordinated with the company.

### 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 are listed below (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 (fund withdrawal), removal of restrictions on chargeable operations and services
#### Mobile app vulnerabilities

This subcategory includes vulnerabilities that affect the server infrastructure through mobile app 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 (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

Out-of-scope submissions include the following:

- Any possible CSRF vulnerabilities within https://community.timeweb.com, https://timeweb.com/ru/community, or https://mail.timeweb.com
- Bitrix-related issues on timeweb.com
- 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
- Any interaction between linked accounts (as it is considered noncritical and lies within the responsibility of the customer)
- 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 Timeweb 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
- Problems with DMARC/SPF, DNSSEC, or DKIM records
- 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
- Possible vulnerabilities within sentry.timeweb.*
- 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)
----------
### Participation rules

By participating in our bug bounty program, you confirm that you have read and accepted these participation rules. Violation of any 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 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 Timeweb 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 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, 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
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

### Rewards
---
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. 

---
##### Reward amounts

| 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 (IDOR) | ₽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 severe vulnerability, the reward amount may be significantly increased.

Discovered vulnerabilities that pose a significant risk to our company and are eligible for a larger reward include the following:

- **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

In such cases, we are willing to consider increasing the reward up to ₽500,000 after assessing the risks and implications for the business.

We appreciate your efforts and are willing to reward you fairly for finding vulnerabilities, which helps 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). Any subsequent reports addressing the same vulnerability will be marked as duplicates. Reports containing similar attack vectors may also be considered duplicates if our security 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 security team.

#### Vulnerability disclosure policy

You may not share any details of the vulnerabilities you discover without written permission of the Timeweb security team.

----------
### Useful information

For general information about our services, go to:

- https://timeweb.com/ru/docs/
- https://cheapsender.notion.site/cheapsender/9d7d9c7d7a1a4228ab13f43da7b7c860
### 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.ru, and we will credit you with a bonus payment for testing.

### How to get a mailbox on mail.timeweb.com

Send an email to bugbounty@timeweb.ru requesting the creation of a mailbox for testing mail.timeweb.com. Make sure to provide a link to your Standoff 365 profile (**your profile must be verified**).
##### Links to the services

- (Cheapsender) https://cp.cheapsender.email/registration
- (Webmasters) https://timeweb.com/ru/partners/webmasters/
- (Community) https://timeweb.com/ru/community/
- (Mail) https://mail.timeweb.com/login

**Issues found within the testing scope are evaluated based on their severity, to the maximum extent applicable. 
However, some cases may be considered on an individual basis if the discovered vulnerability has a significant impact on the whole infrastructure.**

Established in 2006, Timeweb is one of the largest hosting providers in Russia and the CIS. 
With Timeweb, you can easily host your website, register a domain name, rent a virtual or physical server, and get other services for your website to thrive online.

https://timeweb.com/ru/

Programs