OTTO.DE Bug Bounty

Rules

Company

Otto.de is the second-largest online shop in Germany and its currently transitioning to be a leading platform that connects sellers and buyers. Our aim is to provide our customers with a one-stop shop that contains a vast and ever-expanding selection of products.

At otto.de, security is an important component of our organizational culture; we take security issues seriously and work closely with our development teams to not only ensure security during our software development process, but also validate these assumptions through security testing.

This Bug Bounty program is the next logical step that serves as an additional security layer that helps further elevate the privacy and security posture of our site.

We thank you for joining our Program and for your help keeping Otto.de safe!

Program Rules

Testing Policy, Responsible Disclosure

Please adhere to the following rules while performing research on this program:

• Denial of service (DoS) attacks on OTTO applications, servers, networks or infrastructure are strictly forbidden.
• Avoid tests that could cause degradation or interruption of our services.
• Do not use automated scanners or tools that generate large amount of network traffic
• Do not leak, copy, manipulate, or destroy any user data or files in any of our applications/servers.
• No vulnerability disclosure, full, partial or otherwise, is allowed.
• Make sure to apply hunting requirements policy (User-Agent, VPN...)
• During testing, you are only permitted to use data for which you have the appropriate authorization (your own account). This is especially important in the checkout process, where entering unauthorized payment information is prohibited.

Important precautions and limitations

As a complement to the Program’s rules and testing policy :

• DO NOT attempt to gain access to personal data or personally identifiable data of third persons
• DO NOT alter compromised accounts by creating, deleting or modifying any data
• DO NOT use compromised accounts to search for post-auth vulnerabilities (they won’t be eligible anyway)
• DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.
• In case of exposed credentials or secrets, limit yourself to verifying the credentials validity
• In case of sensitive information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.

Reward Eligibility

We are happy to thank everyone who submits valid reports which help us improve the security of OTTO, however only those that meet the following eligibility requirements may receive a monetary reward:

• To be eligible for a reward, we require that issues being reported have an actual security impact in a realistic scenario.
• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability
• The report must contain the following elements:
• Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and OTTO, and remediation advice on fixing the vulnerability
• Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
• Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc
• You must not break any of the testing policy rules listed above
• You must not be a former or current employee of OTTO or one of its contractors.
• We reserve the right to use a "OneFixOneReward" rule, i.e., if two or more endpoints/forms use the same code base and a single fix can be deployed to fix all the ensuing flaws, only one report will be considered as eligible for a reward and other reports will be closed as informative. However, all reports will be reviewed edge by edge.

Reward amounts are based on:

• Reward grid of the report's scope
• CVSS scoring and actual business impact of the vulnerability upon performing risk analysis

Reports of Subdomain Takeovers

For subdomain takeovers that are not within the defined scope but still present a valid proof of concept, a reward of €250 will be granted. We reserve the right to apply the "OneFixOneReward" rule, if multiple subdomains can be attributed to the same team. This is often identifiable by the third level of the subdomain name, such as {TEAM}.[bi|platform|cloud].otto.de. If multiple subdomains for the same team are identified, a single compensation of €250 will be provided, regardless of the number of subdomains.

Reports of Open Redirects

Reports regarding Open Redirects will be classified with severity "low" and rewarded 100 EUR by default, unless you can demonstrate any further impact or exploitation.

Out of scope

• Out-Of-Scope are also other applications hosted under the www.otto.de domain but have a different path, that is not part of our core online shop itself (you will notice, since the design of the page is completely different)
• Those include but are not limited to (if unsure, contact us before executing the tests):
• https://www.otto.de/reblog
• https://www.otto.de/roombeez
• https://www.otto.de/twoforfashion
• https://www.otto.de/soulfully
• https://www.otto.de/updated
• https://www.otto.de/newsroom
• https://www.otto.de/kundenchat
• https://www.otto.de/clara
• https://www.otto.de/user/sendcallbackrequest
• https://www.otto.de/user/contactFormSubmit
• https://keycloak.apps.otto.de
• All domains not listed In-Scope
• /apps-messenger (the chatbot in general is out of scope)
• /tracking
• Please let us know if you have any questions regarding the scope.

Qualifying vulnerabilities

• SQL Injection (SQLi)
• Cross-Site Scripting (XSS)
• Remote Code Execution (RCE)
• Insecure Direct Object Reference (IDOR)
• Horizontal and vertical privilege escalation
• Authentication bypass & broken authentication
• Business Logic Errors vulnerability with real security impact
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
• Cross-Origin Resource Sharing (CORS) with real security impact
• Cross-site Request Forgery (CSRF) with real security impact
• Open Redirect
• Exposed secrets, credentials or sensitive information on an asset under our control and affecting at least one of our scopes

Non-qualifying vulnerabilities

• Broken Link/ Social Media Hijacking
• Tabnabbing
• Missing cookie flags
• Content/ Text injection
• Clickjacking/ UI redressing
• Denial of service (DOS) attacks
• Recently disclosed CVEs (less than 30 days since patch release)
• CVEs without exploitable vulnerabilities and PoC
• Open ports or services without exploitable vulnerabilities and PoC
• Social engineering of staff or contractors
• Presence of autocomplete attribute on web forms
• Vulnerabilities affecting outdated browsers or platforms
• Self-XSS or XSS that cannot used to impact other users
• Any hypothetical flaw or best practice without exploitable vulnerabilities and PoC
• SSL/ TLS issues (e.g. expired certificates, best practices)
• Unexploitable vulnerabilities (e.g. Self-XSS, XSS or Open-Redirect through Http headers...)
• Reports with attack scenarios requiring MITM or physical access to victim's device
• Missing security-related HTTP headers which do not lead directly to an exploitable vulnerability and PoC
• Low Severity Cross-Site Request Forgery (CSRF) (e.g. Unauthenticated/ Logout/ Login / Product cart updates...)
• Invalid or missing email security records (e.g. SPF, DKIM, DMARC)
• Session management issues (eg. lack of expiration, no logout on password change, concurrent sessions)
• Disclosure of information without exploitable vulnerabilities and PoC (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets, EXIF Metadata, Origin IP)
• CSV injection
• Malicious file upload (e.g. EICAR files,EXE)
• HTTP Strict Transport Security Header (HSTS)
• Subdomain takeover without a full exploitable vulnerability and PoC or not applicable to the scope
• Blind SSRF without exploitable vulnerabilities and PoC (e.g. DNS & HTTP pingback, Wordpress XMLRPC)
• Lack or bypass of rate-limiting, brute-forcing or captcha issues
• User enumeration (e.g. email, alias, GUID, phone number, common CMS endpoints)
• Weak password policies (e.g. length, complexity, reuse)
• Ability to spam users (email/SMS/ direct messages flooding)
• Disclosed or misconfigured public API keys (e.g. Google Maps, Firebase, analytics tools...)
• Password reset token sent via HTTP referer to external services (e.g. analytics / ads platforms)
• Stolen secrets, credentials or information gathered from a third-party asset that we have no control over
• Exposed secrets, credentials or information on an asset under our control that are not applicable to the program's scope
• Pre-account takeover (e.g. account creation via oAuth)
• GraphQL Introspection is enabled