Afisha

Policy

• Please provide detailed reports with reproducible steps.
• Submit a separate report for each discovered vulnerability unless you need to chain several vulnerabilities.
• When duplicates occur, we only reward the first report that we receive (provided that the vulnerability described in the report can be fully reproduced).
• Include vulnerabilities that share a similar cause in a single report (for example, if you discover a vulnerability in a library used in multiple domains within the scope).
• If fixing a vulnerability reported earlier also fixes the vulnerability described in a later report, only the former report will be rewarded.
• Be sure to avoid actions that might result in privacy violations, destruction of data, or interruption or degradation of our services. Use only your own accounts. You can interact with the accounts of other users only if they explicitly consent to it.
• Do not run scans that may lead to degraded performance or denial of service of the target applications.
• Do not open or modify our clients' accounts.
• Do not carry out social engineering attacks, including phishing.
• Do not spam.
• Do not conduct physical attacks of any kind.
• After gaining initial access, you must not proceed with lateral movement or post-exploitation.
• We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
• Reports of RCE, SQL, and SSRF vulnerabilities discovered outside of the critical infrastructure will receive smaller rewards. Within the critical infrastructure, the host rm.rambler-co.ru (10.99.2.223) must be available; the expected response from the host is 302.

Report requirements

• The report must be exhaustive and intelligible to the reviewer. It must include all the steps, commands, and dependencies necessary to reproduce the vulnerability. Provide detailed steps that specify what is vulnerable and how it can be exploited. You must also present evidence that backs up your findings, such as screenshots of requests and results or videos demonstrating the entire attack kill chain.
• The report must describe the potential risks related to the vulnerability. We would appreciate it if you would also provide recommendations for remediation.
• Since lateral movement is prohibited, some vulnerabilities can be demonstrated with the following data:
  • SQL injection: database version.
  • XXE or XML injection: demonstration of XXE without DoS.
  • XSS: output of the alert or log message.
  • RCE: hostname, id, ifconfig.
  • SSRF: curl to the internal domain (rm.rambler-co.ru (10.99.2.223); the expected response from the host is 302).

Rewards

Severity scoring criteria

Vulnerabilities

• RCE
• Injections
• SSRF
• LFI/RFI
• XXE

Notes on reporting certain types of vulnerabilities

1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
2. If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.

Out-of-scope submissions

• Clickjacking.
• Login/Logout CSRF.
• Man-in-the-middle (MITM) attacks.
• Use of social engineering methods.
• Self-XSS.
• Any malicious activities that may lead to denial of service.
• Output of automated scanners without a viable proof of concept (PoC).
• HTTP header injections without significant impact (including CRLF).
• SPF, DKIM, or DMARC misconfigurations.
• Lack of SSL/TLS best practices.
• Attacks that require physical access to the company's equipment.
• Vulnerabilities in third-party libraries without immediate security impact.
• Lack of other best practices without immediate security impact.
• Vulnerabilities only applicable to outdated browser versions.
• Obsolete DNS entries.
• Lack of security flags in non-critical cookies.
• Information leaks through the Referer header.
• Information leaks through /status or /metrics without demonstrable security impact.

• Open redirect vulnerabilities if they are not associated with a more critical attack vector.
• Vulnerabilities that can be exploited to drive up user metrics (such as ratings, reactions, and number of followers or reposts), except for CSRF.

Vulnerability disclosure policy

Scope

• *.afisha.ru
• *.daily.afisha.ru
• *.eda.ru
  (Notes on special projects within the scope: Subdomains of the main project may host special projects with low criticality that are not included in the scope of this program. To verify whether a domain is within the program scope, you can check if its IP address falls within the range of the subnet 81.19.64.0/19. Reports on vulnerabilities found in domains with IP addresses from other subnets are accepted either without a reward or with a lower severity level assigned.)

Domains outside the scope:

• school.eda.ru