## Scope 
* api.konsol.pro 
* app.konsol.pro 
* psb.konsol.pro 
* app.restaff.work 
* \*.konsol.team 
* app.algorithm24.ru
* Android: Play Store: com.konsolpro.konsolpro 
* https://apps.apple.com/ru/app/%D0%BA%D0%BE%D0%BD%D1%81%D0%BE%D0%BB%D1%8C/id1566105228 

### The following assets are also in scope, but the maximum reward is ₽7,000:
* konsol.team 
* vpn.konsol.pro 
* konsol.pro

## Out of scope
* konsol.pro/blog

## Notice regarding information security tools
To avoid your traffic being classified as malicious and prevent related issues, you must insert the following HTTP header in every outgoing request: `X-Bug-Bounty`: `username`.

# Reward policy
We assess vulnerabilities on a case-by-case basis using the Vulnerability Rating Taxonomy (VRT) and our expertise. The severity level of a vulnerability can be decreased or increased depending on potential attack impact.


The principal reserves the right to make the final decision on the severity of the discovered vulnerability.


The maximum payouts are only provided for vulnerabilities found in services listed under the Scope section—that is, within the main program scope. 
All other assets have a reduced (or, in some cases, zero) coefficient for calculating the reward amount.

No rewards are provided for the following submissions:
* Self-XSS, XSS in unpopular or outdated browsers, and flash-based XSS.
* CSRF and XSS that do not affect sensitive data.
* Lack of recommended protection mechanisms* (for example, HTTP headers, cookie security flags, or anti-CSRF protection).
* CORS misconfigurations.*
* Use of outdated or potentially vulnerable third-party software.*
* Attacks related to fraud or theft.
* Ability to send unlimited SMS and email messages.
* DoS attacks.*
* Insecure SSL/TLS configuration.*
* Disclosure of a username, email address, or phone number that exists in the system.
* Full path disclosure.
* Disclosure of technical or non-sensitive information* (such as product or software versions and stack traces).
* Open redirect vulnerabilities that do not involve other attack vectors (for example, authorization token theft).
* Page content spoofing.
* Tabnabbing.
* Vulnerabilities with overly sophisticated, unrealistic, or unlikely user interaction scenarios.
* Vulnerabilities that require malware, root access, or a jailbroken device for exploitation.
* Attacks that require MITM of someone else's connection or physical proximity to another device (for example, attacks via NFC, Bluetooth, Wi-Fi, and shoulder surfing).
* Improbable or hypothetical attacks without proof of their feasibility.
* Without a detailed description of the attack vector and proof of potential negative impact.*

## Reports on the following will not be considered
* Vulnerabilities in services that are not part of the Konsol.PRO ecosystem.
* Issues not related to security.
* Possible DDoS attacks.
* Information about IP addresses, DNS records, and open ports.
* Use of phishing and other social engineering methods.
* Publicly available login panels.
* Disclosure of publicly available user information.
* Weaknesses related to the use of four-digit SMS codes.
* Bypass of root and jailbreak detection.
* Potential for reverse engineering of the mobile applications.
* Messages from security scanners and other automated systems.
* Reports on vulnerabilities without demonstration that they actually exist.
* Reports on vulnerabilities with no indication of credibly possible negative impact of their exploitation.
* Missing security headers.
* Clickjacking attacks exploiting missing HTTP headers. For a clickjacking report to be considered, you must provide a valid proof of concept (PoC) and describe the attack scenario and negative impact of the attack.
* Lack of best security practices.
* MITM attacks or attacks that require physical access to a user's device.
* Vulnerabilities that only affect users of outdated or vulnerable browsers and platforms.
* Vulnerabilities that can only lead to self-inflicted negative impact.

# Testing rules
* For testing, you can only use your own accounts or accounts of users who have explicitly given their consent to such activity.
* Prepare detailed reports describing steps to reproduce the attack scenario. If your report does not contain sufficient information to reproduce the problem, you may be disqualified from receiving the reward.
* To confirm the presence of a vulnerability, provide the minimum possible proof of concept (PoC). If this could impact other users or the system's performance, please contact the principal to get permission.
Further exploitation of vulnerabilities is strictly prohibited.
* You must not launch automated brute-force attacks, conduct DoS or DDoS attacks, send spam to our users, or use social engineering or phishing techniques to target our employees or contractors.
* Contacting technical support and submitting any forms to be processed by humans are strictly prohibited.
* When duplicates occur, we only reward the first reporter of the vulnerability (provided that the scenario described in the first report can be fully reproduced).
* Reports offering solutions to problems that we are aware of and that are already being addressed do not qualify for a reward.
* Do not disclose information about a discovered vulnerability to anyone without our permission.
* Reports on publicly-disclosed 0-day vulnerabilities with an official patch released less than two weeks before the report submission may be considered duplicates if they are already known to our team from public sources.
* While searching for vulnerabilities, avoid compromising the confidentiality, integrity, and availability of information in the principal's 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.

* Automated scanning tools must be limited to five requests per second.

## RCE testing rules
When testing for remote code execution (RCE) vulnerabilities, you must adhere to the following policy.


Only the following actions are allowed on the server:
* Execute the ifconfig (ipconfig), hostname, and whoami commands.
* Read the contents of the /etc/passwd and /proc/sys/kernel/hostname files (drive:/boot.ini, drive:/install.ini).
* Create an empty file in the directory of the current user.


Any other actions must be coordinated with the principal.

## SQL injection testing rules
When testing for SQL injection vulnerabilities, you 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 principal.

## File read and upload rules
When testing for arbitrary file read vulnerabilities or arbitrary file upload vulnerabilities on the server, you must adhere to the following policy.


 When uploading files, you must not do the following:
* 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.
* 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, you are 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 triager.

## Report requirements
One report should describe one vulnerability. The only exception is when vulnerabilities are interconnected or can be combined into a chain.


A vulnerability report must contain the following:
* Vulnerability description
* Steps to reproduce
* Threat analysis
* Recommendations for remediation


The report must also include:
* URL of the vulnerable application
* Vulnerability type
* Screenshots or video recordings demonstrating the vulnerability and the steps to reproduce it
* Example of a formatted request from Burp Suite (or any other PoC)
* Code fragments (if applicable)

Konsol

At Konsol, we automate the management of employees with different tax statuses (individuals, self-employed persons, and private entrepreneurs) and help medium and large companies to reduce costs and lower risks related to working with a large number of contractors.

Автоматизируем управление самозанятыми, ИП, физлицами. Помогаем средним и крупным компаниям сократить издержки и снизить риски сотрудничества с большим числом исполнителей

Programs