Zero-Click Account Takeover in Major E-Commerce Platform

### Background & Executive Summary During responsible security assessments of distributed e-commerce architectures, vulnerabilities rarely exist in isolation as single, blatant remote-code execution flaws. Instead, modern breaches almost universally arise from **subtle semantic disconnects between microservices**. In this research, I chained three seemingly harmless low-severity behaviors: 1. **An unvalidated header reflection** in an upstream reverse proxy. 2. **A loose OAuth2 state parameter validation routine** in the authentication gateway. 3. **A race condition during password reset token consumption**. Together, these flaws permitted an adversary to poison the password reset callback URL and silently hijack the authentication session of any targeted user. --- ### Step 1: The Upstream Reverse Proxy Quirk The target architecture utilized an Envoy reverse-proxy cluster routing traffic to backend Node.js and Go microservices. While examining the password reset endpoint: ```http POST /api/v1/auth/reset-password HTTP/1.1 Host: auth.target.com X-Forwarded-Host: attacker-controlled.com Content-Type: application/json {"email": "victim@domain.com"} ``` The application did not immediately reflect `X-Forwarded-Host` in the generated email link. However, by fuzzing alternative headers, I observed that `X-Original-Host` caused the internal mailer worker to construct: ``` https://attacker-controlled.com/auth/verify?token=ey829... ``` --- ### Step 2: Bypassing Rate Limits via Header Rotation The endpoint enforced an initial rate limit of 5 requests per 10 minutes per IP. By rotating through Cloudflare edge IP representations (`CF-Connecting-IP` simulation and IPv6 ranges), the threshold was bypassed, confirming an architectural deficiency in distributed rate calculation. --- ### Remediation & Lessons for Defense - **Canonical Host Enforcement:** Never derive hostnames from incoming HTTP headers without strict whitelist verification. - **Atomic Token Invalidation:** Password reset tokens must be bound to a cryptographically secure hash of the user's current password hash so that changing the password immediately renders all historical tokens inert.