By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigrity Terms and Conditions
• Respect the scope of the program.
• Domains/IP Addresses that belong to Zalando will only be accepted.
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo).
• Before causing damage or potential damage: Stop, report what you've found and request additional testing permission.
• Only storing all supporting evidence and other attachments within the report you submit. Do not host any files on external services.
• Only use authorized accounts so as not to inadvertently compromise the privacy of our users
• Not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), and File Upload vulnerabilities are listed above.
• Not try to exploit service providers we use, prohibited actions include, but are not limited to brute forcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-Zalando owned property/system/service/data.
• Researchers may not, and are not authorized to engage in any activity that would be disruptive, damaging or harmful to Zalando, its brands or its users. This includes: social engineering (e.g. phishing, vishing, smishing), physical security and denial of service (DoS) attacks against users, employees, or Zalando as a whole.
• Please limit any automated scanning. Aggressive testing that causes service degradation will be grounds for removal from the program.
• Vulnerabilities discovered in a testing/staging environment will be considered as a Low Severity Vulnerability.
• Zalando internal employees cannot participate in the program. Any discovered vulnerabilities need to be reported in adherence to the internal vulnerability management process.

Thank you for helping keep Zalando and our users safe!

Introduction

Please see our detailed scope and out-of-scope list. This list is subject to change without notice.

If you’ve found a vulnerability that affects an asset belonging to Zalando, but is not included in the scope, please report it to this program.

Our worst-case scenarios are:

• Extraction of Personal Identifiable Information (PII)
• Purchasing products for free
• Remote Code Executions (RCEs)

Valued Vulnerabilities

• Remote Code Execution / OS Command Injection
• Injection (SQLi, LDAP, XML, etc.)
• Business Logic Bypass
• Sensitive Data Exposure (PII, financial, credentials on GitHub, private keys, etc.)
• Significant Authentication Bypass
• Server Side Request Forgery (SSRF)
• Server Side Template Injection
• File Inclusion (Remote/Local)
• XML External Entity Injection (XXE)
• Memory leaks
• Cross Site Scripting (Stored, Reflected, Blind)
• Authorization Bypass (Privilege Escalation, IDOR, etc.)
• Subdomain Takeover

Remote Code Execution (RCE) Policy
Vulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance with this policy.

Prohibited actions when conducting RCE attempts:

• Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)
• Altering file permissions
• Reading sensitive files on the system (e.g. /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)
• Altering/Modifying/Deleting any files on the system.
• Copying any files from the system and disclosing them to a non Zalando site or entity
• Interacting with underlying OS-level data and/or databases.
• Interacting with other services running on the OS-level and/or any remote hosts residing on the network.
• Interrupting the normal operation of the server.
• Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.

Allowed actions when conducting RCE attempts - Unix:

• Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands
• Reading content of the '/etc/passwd' file
• Using 'echo' to pipe characters into a file located in the "/tmp/", reading the file and then removing it right after confirmation.

Allowed actions when conducting RCE attempts - Windows:

• Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands
• Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'
• Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.

SQL Injection (SQLi) Policy
Vulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.

Prohibited actions when conducting SQLi attempts:

• Reading sensitive files on the system (e.g. /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)
• Reading specific sensitive database records
• Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE
• Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)
• Creating/Deleting Users
• Reading/Altering Username and Password information (includes password hashes)
• Interrupting the normal operation of the server and the database.

Allowed actions when conducting SQLi attempts:

• Executing SELECT queries such as "@@version", "user();" "system_user();", "database();", "@@hostname"
• Listing Databases names from schema, listing Columns, Table names
• Executing Mathematical, conversion or logical queries, such as:
• ASCII Value -> Char (SELECT char(65); # returns A) Char -> ASCII Value (SELECT ascii(‘A’); # returns 65) String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC) Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A) SELECT 0×414243; # returns ABC Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )
• Using Logic and time in Server Responses
• Using output responses

File-Upload Policy

• Vulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module, etc.) are subjected to these rules
• Prohibited actions when conducting File-upload attempts:
• Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement)
• Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.)
• Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.)
• Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)
• Allowed actions when conducting File-upload attempts:
• Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.
• Upload of a file (any extension) with no content, simple string, integer or a special character.

Feedback
Would you like to help us improve our program or have some feedback to share, please send your anonymous feedback here:

Program feedback link
Please note this form will be checked periodically and should not be used for submission or support queries.

Application

• Missing Security Best Practices (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)
• Subdomain Takeover without working Proof-of-Concept (for example, Subdomain pointing towards third-party services such as Squarespace)
• Broken Link Hijacking (Facebook, Instagram, Pinterest, Twitter, YouTube, etc.)
• Use of a known-vulnerable libraries or frameworks - for example an outdated jQuery or AngularJS (without clear and working exploit)
• Missing cookie attributes (secure, HTTPOnly, path, etc.)
• External Server Interaction (DNS/HTTP) without working Proof-of-Exploitability (for example, SSRF without internal IP interaction)
• Comma Separated Values (CSV) injection
• HTML content injection/iFrame injection (unless significant impact can be achieved with minimal user interaction)
• Disclosure of internal tracebacks (unless sensitive environment data is also leaked)
• Unauthenticated access to k8 APIs w/o exploitation PoC
• HTTP Request Smuggling (without clear and working exploit)
• SSL/TLS Best Practices and Weak Certificate Hash Algorithm
• Physical attacks
• Results of automated scanners
• Not stripping metadata of images
• Autocomplete attribute on web forms
• Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)
• API key leaks with no security consequences (e.g. Google Maps API key leak)
• Verbose error pages (without proof of exploitability)
• Missing Security HTTP Headers (without proof of exploitability)
• "Self" XSS (without evidence on how the vulnerability can be used to attack another user)
• Clickjacking/UI Redressing
• Reflected file download
• Incomplete/Missing SPF/DKIM/DMARC records
• Social Engineering attacks (including phishing)
• Login/Logout/Unauthenticated CSRF
• Issues related to networking protocols
• Software Version Disclosure (for example using identifying Apache Tomcat 8.0.43 but not being able to perform any attack)
• Denial of Service attacks (DoS & DDoS attacks are strictly not permitted)
• Internal pivoting, scanning, exploiting, or exfiltrating data
• Rate limiting or brute force issues
• Interacting with other accounts without the consent of their owners. Test only with your own user profiles when researching vulnerabilities
• Attacks only exploitable on older browsers
• Open redirects - unless they can be used for actively stealing tokens
• Disclosure of known public files or directories (e.g. S3)
• Vulnerabilities that are strictly client side
• Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a Zalando-related account
• Flash file vulnerabilities
• Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these
• Lack of HTTPS
• Information disclosure (Server Banner, Technology used, Full Path, Private IP, Hostname, etc.)
• CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)
• Host Header Injection (Unless it gives you access to interim proxies)
• Cache Poisoning (without clear and working exploit)
• OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario
• Public Google calendars

General

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Vulnerabilities that only work on software that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• 0-day and other CVE vulnerabilities may be reported 30 days after initial publication (CVE List Status of PUBLISHED). We have a team dedicated to tracking CVEs as they are released; hosts identified by this team and internally ticketed will not be eligible for bounty.
• Third-party Apps/add-ons/integrations are strictly excluded (vulnerabilities that exist within third-party apps in any way); we will pass on any vulnerabilities found. However, they can only be considered for a bounty based on their impact and Zalando's ability to mitigate/remediate the vulnerability, independently, without waiting for an official patch from the vendor. In either case, the eligibility lies at the sole discretion of Zalando.
• Reports that state that software is out of date/vulnerable without a proof-of-concept

Mobile

• Shared links leaked through the system clipboard
• Any URIs leaked because a malicious app has permission to view URIs opened
• The absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• Lack of obfuscation
• Path disclosure in the binary
• Lack of jailbreak & root detection
• Crashes due to malformed URL Schemes
• Lack of binary protection (anti-debugging) controls, mobile SSL pinning
• Snapshot/Pasteboard leakage
• Runtime hacking exploits (exploits only possible in a jailbroken environment)
• API key leakage used for insensitive activities/actions

This program follows Intigriti's contextual CVSS standard

What is a Non-Paid Vulnerability Disclosure Program?
Our Non-Paid Vulnerability Disclosure Program is a platform that allows security researchers and ethical hackers to report security vulnerabilities in our systems, applications, or services. While we do not offer monetary rewards for submissions, we highly value your contributions and acknowledge your efforts to improve our security.

Why should I participate in the program if there's no monetary reward?
Participating in our program offers several benefits, including:
Recognition: We acknowledge your contributions to Intigriti, which gives you points on the platform.
Skill Development: Engaging in vulnerability research helps you hone your skills and gain experience in cybersecurity.
Contribution to Security: By reporting vulnerabilities, you help us protect our users and enhance the overall security of our services.

What happens after I submit a report?
Once you submit a report:
Acknowledgment: You will receive an acknowledgment email confirming that we have received your report.
Review: Our security team will review the submission, assess the severity, and validate the vulnerability.
Remediation: If the vulnerability is confirmed, we will work to fix it.

Will my submission be kept confidential?
Yes, all submissions are treated with confidentiality. We will not publicly disclose any details of your submission.

Can I publicly disclose the vulnerability after reporting it?
Responsible disclosure is crucial to ensuring that the vulnerability does not pose a risk to our users. Once the issue is resolved, we can discuss the possibility of a coordinated disclosure.

How long does it take for vulnerabilities to be addressed?
The timeframe for addressing vulnerabilities varies depending on the severity and complexity of the issue. Our team will work diligently to resolve vulnerabilities quickly and keep you informed throughout the process.