Our code of conduct

• We respect the time and efforts of our researchers.
• We will reply to you within 15 business days.
• We aim to process the report within 30 business days of replying to your submission.
• If we need more time to process the report, we will let you know.
• We will define the reward amount within 30 business days of finishing triage.
• We will do our best to keep you informed about our progress throughout the entire process.

Your code of conduct

• Be an ethical hacker and respect the privacy of other users.
• Avoid actions that might result in privacy violations, destruction of data, or interruption or degradation of our services.
• If you are going to pentest SberLogistics under a user account, be sure to include the word "Standoff" into the user name value when registering as a user. This will help to avoid the potential blocking of the account.
• When using automated security scanners, make sure they make no more than 30 requests per second to a single host (including all concurrent streams and all scanners running simultaneously).
• Carefully read the program terms and conditions before proceeding with your research.
• Try to provide information about the discovered vulnerabilities promptly and accurately.

Disclaimer: SberLogistics uses the AntiDDoS/Antibot protection by ServicePipe. If you detect the X-SP-CRIDheader or get_cookie_spsc() | *.spsc*. functions on a page, it is a ServicePipe stub page.

Scope

• Reports generated by security scanners and other automated tools.
• Information about IP addresses, DNS records, and open ports.
• Reports of issues and vulnerabilities based on the product version without demonstrating exploitation.
• Reports of vulnerabilities whose exploitation is prevented by information security tools (such as WAF) without demonstrating how to bypass the security tools.
• Reports of insecure SSL/TLS ciphers without demonstrating exploitation.
• Reports of vulnerabilities already reported by other participants (duplicate reports).
• 0-day or 1-day vulnerabilities publicly disclosed less than 30 days before the report submission and vulnerabilities with a CVSS score higher than 8 disclosed less than 14 days before the submission.
• Self-XSS and other vulnerabilities that do not directly affect users or application data.
• Vulnerabilities that can only be exploited via browser versions released six or more months before the report submission or browser versions that are no longer supported.
• Reports of cross-origin resource sharing (CORS) misconfigurations without demonstrating exploitation.
• Disclosure of a username, email address, or phone number that exists in the system.
• Disclosure of technical or non-sensitive information (for example, product or software versions and stack traces).
• Tabnabbing.
• Clickjacking.
• Reports of Content Security Policy (CSP) issues for domains without CSP and domain policies with 'unsafe-eval' and/or 'unsafe-inline'.
• Attacks that rely on full access to a local account or browser profile.
• Disclosure of sensitive user information via third-party resources that SberLogistics has no control of (such as spyware).
• Vulnerabilities with overly sophisticated, unrealistic, or unlikely user interaction scenarios.
• Lack of best practices in DNS and mail service configuration (such as DKIM, DMARC, SPF, and TXT).
• Broken or outdated links to social media pages and similar resources.
• Ability to perform an action unavailable via the user interface without identifiable security risks.
• Unlimited ability to create user accounts.
• User enumeration.
• Disclosure of publicly available user information.
• Lack of notifications about important user actions.
• Leakage of sensitive tokens (such as password reset tokens)
  to trusted third parties over a secure connection (HTTPS).
• Takeover of accounts of employees who are not related to development or do not have access to sensitive information.
• Issues not related to security. (Please report such issues to our technical support: alekmorozov@ecom.tech)

Our obligations

1. Promptly address identified security issues.
2. To not prohibit the disclosure of vulnerabilities without good reason.
3. To not make baseless accusations against researchers.

Public vulnerability disclosure

Prohibited actions

• Gain access to data belonging to another user without the user's permission, change or destroy the data, or disclose any sensitive data obtained inadvertently during the vulnerability testing process or exploit demonstration. Deliberate access to sensitive data is prohibited and can be deemed illegal.
• Tamper with user accounts without their owners' permission.
• Use detected vulnerabilities for personal purposes.
• Use vulnerability testing tools that automatically generate large amounts of traffic and cause resource exhaustion attacks.
• Conduct attacks that compromise integrity and availability of services (for example, DoS and brute-force attacks) or attempt to exploit a resource exhaustion vulnerability. If you find such a vulnerability, report it to the SberLogistics security team for simulation of an attack in a test environment.
• Perform physical attacks on Okko employees, data centers, or offices.
• Spam or carry out social engineering attacks (phishing, vishing, and so on) against SberLogistics customers, partners, or employees.
• Analyze server infrastructure where web applications are hosted.
• Disclose information about a vulnerability before public disclosure by SberLogistics.

RCE testing rules

• Execute the ifconfig (ipconfig), hostname, whoami, and id 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 our security specialists.

SQL injection testing rules

• 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 our security specialists.

File read and upload rules

• 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 an 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 files such as /etc/passwd and /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini). Any other actions must be coordinated with our security specialists.