Azbuka Vkusa pays great attention to the security, integrity, and availability of its data and systems in an effort to provide the best experience to its customers, employees, and partners. We value the work of security researchers who help us make our products and services safer and encourage the community to participate in this bug bounty program.
Reports generated by automated vulnerability scanners (and not accompanied by the researcher's analysis) are considered out of scope.
Response time
As a rule, we aim to meet the following time frames:
• Time to response (from data submission): 5 business days.
• Time to triage of the report (from full report submission): 10 business days.
• Time to bounty (from the end of report triage): 20 business days.
These times may be extended during weekends and national holidays.
Disclosure policy
• Follow the general principles of responsible information disclosure.
• Do not disclose information about vulnerabilities (even if they have been fixed) and do not forward this information to third parties without express consent from Azbuka Vkusa.
• Do not use the discovered vulnerability for your personal or someone else's benefit other than this program's owner's. This requirement includes exposing additional risks and attempting to disclose confidential data or find other vulnerabilities.
Program rules
General rules
• The reward amount depends on the severity of the discovered vulnerability.
• If duplicates occur, we will only pay a bounty for the first submitted report (provided that the vulnerability described in the report can be fully reproduced).
• Multiple reports of vulnerabilities or a single report of multiple vulnerabilities caused by one underlying issue will be awarded one bounty. It means the same vulnerability discovered in multiple domains will be treated as a single vulnerability. Please include all affected domains in a single report, as all subsequent reports will be taken as duplicates.
• Test accounts may be provided on request, but only in exceptional cases.
• Out-of-scope reports will be taken into account but will not be rewarded.
• Azbuka Vkusa employees (current or former) and their affiliates cannot participate in the program.
Vulnerability testing and reporting rules
• Provide detailed reports with reproducible steps, including full requests used for vulnerability exploitation.
• Submit one report per vulnerability unless multiple vulnerabilities must be exploited for a successfully attack.
• Do not disclose information about vulnerabilities or forward it to third parties.
• Do not use vulnerability testing tools that automatically generate large amounts of network traffic and/or significantly increase traffic frequency.
• Do not carry out attacks that could harm the reliability and/or integrity of Azbuka Vkusa's services or data (such as denial-of-service attacks).
• Do not open or make changes to customer accounts. If necessary, use your own accounts to test for vulnerabilities.
• Do not spam or carry out social engineering attacks (including phishing) against the company's customers and employees.
• Do not perform physical attacks of any kind.
• Note that post-exploitation of the vulnerability after the report submission is prohibited.
Scope definition within the program policy
In scope:
Services:
• Services located on the domains: av.ru (and subdomains), azbukavkusa.ru (and subdomains).
• Services located at the network addresses: 195.19.210.0/24.
• Services available on Azbuka Vkusa's wireless networks as well as wireless networks belonging to the company.
Vulnerabilities:
The scope is limited strictly to technical vulnerabilities in Azbuka Vkusa's services and web applications. Any design or implementation vulnerability that significantly affects the confidentiality or integrity of data is likely to be applicable to this policy.
Discovered vulnerabilities should be reproducible in the following browsers: Chrome, Firefox, Safari, Opera, Edge, Internet Explorer.
At the time of report submission, the browsers should be updated to the latest version (latest stable release). Vulnerabilities that require the installation of certain services, extensions, or plugins are out of scope.
Out of scope:
Services:
Any services that are not listed as in scope are out of scope.
Web pages that redirect to other domain names are also out of scope.
Vulnerabilities:
• CSRF vulnerabilities for non-critical actions (logout and others).
• Vulnerabilities such as Self-XSS without demonstration of real security impact for users or systems.
• Framing and clickjacking vulnerabilities without a documented series of clicks that proves the existence of the vulnerability.
• Lack of security mechanisms and/or non-compliance with best practices without demonstration of real security impact for users or systems.
• Absence of SSL/TLS or use of insecure SSL/TLS ciphers.
• Google or Yandex API keys.
• Attacks requiring full access to passwords, tokens, browser profiles, or local systems.
• Disclosure of non-critical information (such as the product version or protocol in use).
• Issues that do not affect the most recent browser versions or errors related to browser extensions.
• Vulnerabilities that only affect users with certain browsers.
• Attacks that require extremely unlikely user interaction.
• Denial-of-service attacks or vulnerabilities related to request frequency limits.
• Timing attacks that prove the existence of things such as a user account.
• Insecure cookie settings (for non-critical cookies).
• Errors in the content or services that are not owned or managed by Azbuka Vkusa (including third-party services running on subdomains).
• Vulnerabilities regarded by Azbuka Vkusa as tolerable risks.
• Scripting or other automation and bruteforcing of intended functionality and parameters.
• Absence of a DMARC record on subdomains.
Reports of zero-day vulnerabilities in third-party software will be considered on a case-by-case basis, with no reward guaranteed.
Report requirements
A report must contain a detailed description of the discovered vulnerability and either a description of its exploitation or a proof of concept (PoC). You can attach videos and screenshots to your report, but they cannot replace the report (it must be filled out).
When preparing your report, be sure to include the following:
• Vulnerability name.
• Product name and version of the vulnerable software (or component).
• PoC or detailed description of how to reproduce the discovered security issue.
• Description of the attack scenario: who may want to exploit the vulnerability, for what purpose, how it is exploited, and other information.
• Recommendations for remediation.
Post-exploitation of vulnerabilities after report submission
After you submit a vulnerability report, any further exploitation (post-exploitation) of the vulnerability will be considered to be out of scope, except for the minimum steps required to demonstrate the exploitation of the vulnerability.
For RCE or injection attacks, you can enter commands specifying the database version, system name, or local IP address.
Post-exploitation of a vulnerability that would result in further vulnerabilities and/or risk of compromising the system's stability or integrity is considered out of scope.