We prioritize the security of our products and our users' data. Therefore, we encourage public discovery of security issues and responsible disclosure of them. Please read the rules of our bug bounty program below.
The first researcher to report a previously unknown, valid vulnerability may receive a reward. We offer monetary rewards and branded gifts. The reward amount depends on the severity of the vulnerability found.
We evaluate vulnerabilities individually, taking into account [CVSS](https://nvd.nist.gov/vuln-metrics/cvss) and our expertise. A vulnerability's severity may be increased or decreased depending on the potential damage if implemented and the complexity of exploitation.

# Traffic identification
To ensure proper traffic identification, please add the X-BugBounty: {username} header to each request, where username is your nickname on the Standoff365 platform. This will help us distinguish your traffic from malicious traffic and avoid unnecessary blocks.

# Rules for us
* We will respond within 7 business days.
* We process reports within 14 business days after the response.
* We may extend the processing time for reports but in this case, we will inform you about the delay.
* We will determine the reward amount within 14 business days after processing.
* We will do our best to keep you informed of our progress while processing the report.
* In case of a duplicate we will only award the first report received (provided that it is fully reproduced).
* Issues known to us that are in the process of being fixed are not eligible for compensation.
* Public 0-day vulnerabilities with an official patch released less than 2 months ago may be considered duplicates if they are known to our team from public sources.

# Rules for you
* Before starting your research please read the rules specified in this program
* Provide detailed reports with reproducible steps and an attack scenario. If your report is insufficiently detailed to reproduce the issue, it may be disqualified from receiving the reward.
* When searching for vulnerabilities, avoid compromising the confidentiality and integrity of data, or the availability of our products.
* Do not conduct automated brute-force attacks, denial-of-service attacks (DoS and DDoS), send spam to our users, or engage in social engineering or phishing of our employees and contractors.
* During testing we recommend limiting the scanning tools to 10 requests per second.
* Use only your own accounts for testing purposes. Do not attempt to gain access to other user's accounts or any confidential information.
* When testing, use the lowest possible PoC to confirm the vulnerability. If this may affect other users or the system's performance, please contact us for permission.
* Do not share information about the vulnerability found with anyone without our permission.
* When testing RCE, SQLi, LFI, LFR, SSTI, it is allowed to use only the MINIMUM possible POC for proof (sleep, read /etc/passwd, curl).
* If you discover multiple security issues while investigating Kontur services, prepare separate reports for each vulnerability.

# Scope
We are interested in information about vulnerabilities in all our [products] (https://kontur.ru/products).
## Domains:
* *.kontur.ru
* https://bank.kontur.ru (In the application for opening a bank account**, it is mandatory** to use the same email address as on the Standoff Bug Bounty platform. Otherwise, Kontur may consider testing as an attempt to influence the bank's infrastructure without authorization)
* *.skbkontur.ru
* *.kontur.host (Only critical server-side vulnerabilities are awarded if the vulnerability threatens the infrastructure (for example, RCE, SQLi, LFR, SSRF, etc.) or leaks personal and sensitive data through a vector on the server side. Client-side vulnerabilities (XSS, CSRF) and business logic errors, including privilege escalation within the product, are accepted without reward)
### Vulnerabilities found on other Kontur domains are also accepted, but the decision on the reward is left to Kontur's discretion.
## Mobile Apps:
* All developer apps [SKB Kontur] (https://play.google.com/store/apps/dev?id=4848911796475635929) in Google Play
* All developer apps [SKB Kontur] (https://apps.apple.com/ru/developer/skb-kontur/id417000920?see-all=i-phonei-pad-apps) in the App Store
* [Kontur.Bank for Business](https://play.google.com/store/apps/details?id=com.kontur.bank&hl=ru) in Google Play (In the application for opening a bank account**, you must** use the same email address as on the Standoff Bug Bounty platform. Otherwise, Kontur may consider testing as an attempt to influence the bank's infrastructure without authorization)
* [Kontur.Bank for bussines] (https://apps.apple.com/ru/app/%D0%BA%D0%BE%D0%BD%D1%82%D1%83%D1%80-%D0%B1%D0%B0%D0%BD%D0%BA-%D0%B4%D0%BB%D1%8F-%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%D0%B0/id6449187383) in the App Store (In the application for opening a bank account**, you must** use the same email address as on the Standoff Bug Bounty platform. Otherwise, Kontur may consider testing as an attempt to influence the bank's infrastructure without authorization)

## IP addresses:
* 46.17.200.0/21
* 185.161.180.0/22
* 91.221.248.0/23
* 89.169.16.0/22

# Exceptions from the program
## We do not consider or accept as vulnerabilities:
* Non-security issues.
* Problems related to social engineering and phishing.
* XSS, CSRF, incorrect configuration of CORS, clickjacking, tabnabbing with no real impact on security.
* Use of third-party components with known vulnerabilities without a real attack vector or security impact.
* Reports from security scanners and other automated scanning tools.
* Reports that do not demonstrate the actual presence of the vulnerability.
* Reports that do not indicate possible negative consequences.
* Attacks that require MITM.
* Disclosure of information about IP addresses, DNS records, and open ports of Kontur services.
* Reports on insecure SSL/TLS ciphers without exploitation proof.
* Physical attacks on the Kontur's property or its data centers.
* CSV formula injections.
* No CSP policies on the domain or an insecure CSP configuration.
* The presence of an autofill attribute on web forms.
* No Rate Limit with no proven impact on security.
* Presence or absence of SPF and DKIM records.
* Reports of vulnerabilities in passwords or password policies and other user authentication data.
* Ability to decompile or reverse engineer applications.
* No mechanism or insufficiently secure implementation of SSL /Certificate pinning.
* Lack of integrity control in apk files.

## The vulnerabilities listed below are not considered critical and are not subject to reward:
* Messages about best security practices.
* Absence of security headers, cookie flags, etc.
* Theoretical attacks without proof of exploitation.
* Content substitution and text injection (except for HTML injection).
* Disclosure of non-sensitive information with no real impact on security (for example, software version, detailed error message).
* Vulnerabilities in third-party software products, except for insecure configuration.
* Vulnerabilities that require root access, a specially modified device, or physical access to the device.
* Vulnerabilities that only affect users of outdated or vulnerable browsers and platforms.
* Vulnerabilities that can only harm yourself.
* Email spam with messages from Kontur services, if the attacker cannot control a significant part of the message and cannot insert clickable links in it.
* XSS in the headers: Host, User-Agent, Referer, Cookie, etc.
* Vulnerabilities in partner services (Only critical server-side vulnerabilities are awarded if the vulnerability threatens the Kontur infrastructure (for example, RCE, SQLi, LFR, SSRF, etc.) or leaks of personal and sensitive data of the Kontur and its clients through a vector on the server side).
* Vulnerabilities on mobile devices that require root privileges, jailbreak, or any other modification of applications or devices to be exploited.
* Disclosure of public API keys.
* Scripting in PDF documents.
* Reflected file download.
* DLL-hijacking, the exploitation of which requires modification of the system using local access.
* Spam via mass support requests or similar actions without technical impact on security.


# Report Requirements
The vulnerability report should describe a single vulnerability or a chain of related vulnerabilities and should include:
* Vulnerability description
* Reproduction steps
* Possible consequences
* Recommendations for fixing the vulnerability

## Public disclosure of vulnerability information
Public disclosure by mutual agreement. Kontur undertakes to communicate openly with researchers about the timing of information disclosure. The parties can choose the time when the contents of the report will be made public.

## Unacceptable actions
Researchers are not allowed to:
* Gain access to another user's data without their consent, modify and destroy it, and disclose any confidential information randomly obtained during the search for vulnerabilities or their demonstration. Deliberate access to this information is prohibited and may be considered illegal.
* Influence other users ' accounts without their permission.
* Use the discovered vulnerability for personal purposes.
* Use vulnerability testing tools that automatically generate significant amounts of traffic and lead to resource-depletion attacks.
* Conduct attacks that harm the integrity and availability of services (for example, DoS-attacks, brute-force attacks), or attempt to exploit a resource-depletion vulnerability. You should report the issue to the Kontur security team, who will conduct the attack in a test environment.
* Conduct physical attacks on employees, data centers, and company offices.
* Conduct attacks on Kontur's systems using social engineering techniques (phishing, vishing, etc.) and spam mailings to customers, partners, and employees.
* Explore the server infrastructure where web applications are hosted.
* Disclose information about vulnerabilities before they are publicly disclosed by Kontur.

## RCE Testing Policy
Testing vulnerabilities that may lead to remote code execution should be performed in accordance with the rules set out below.

During testing, any actions on the server are prohibited except:
* Executing commands ifconfig (ipconfig), hostname, whoami, id
* Reading the contents of /etc/passwd and /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini) files
* Creating an empty file in the current user's directory

If any other actions are necessary, they must be agreed with our security specialists in advance.

## SQL Injection Testing Policy
Testing for vulnerabilities that may lead to the introduction of SQL commands should be performed in accordance with the rules set out below.

During testing, any actions on the server are prohibited except:
* Getting data about the current database (SELECT database()), its version (SELECT @@version), the current user (SELECT user(), SELECT system_user()) or the hostname (SELECT @@hostname)
* Getting a database schema (SELECT table_schema), a list of tables in it (SELECT table_name), and column names in tables (SELECT column_name)
* Performing mathematical, conversion, or logical queries (including using SLEEP) without extracting data (except those listed above)

If any other actions are necessary, they must be agreed with our security specialists in advance.

## File Upload and Read Policy
Testing vulnerabilities that can lead to reading arbitrary files on the server or downloading files at random should be performed in accordance with the rules set out below.

Prohibited actions when uploading files:
* Changing, modification, deletion and replacement of any files on the server (including system files), except for those associated with your account or with the account of a user who has explicitly expressed his consent;
* Uploading files that may cause denial of service (for example, large files).
* Download malicious files (such as malware or spyware).

When you get the ability to read arbitrary files on the server, any actions other than reading files such as /etc/passwd and /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini) are prohibited. If other actions are necessary, you must first coordinate them with our specialists.

Kontur

Kontur is a business ecosystem. Kontur offers over 70 products used by every third business in the country: online reporting and accounting, electronic document management, labeling, cloud inventory management and online cash registers, counterparty verification, information security, and electronic signatures for any task.

Kontur is a business ecosystem offering over 70 products trusted by one in three businesses in Russia. Its solutions span online accounting and reporting, electronic document management, labeling, cloud inventory management, online cash registers, counterparty verification, information security, and electronic signatures.

Programs