Summary

Beneath the surface of a seemingly routine preference-saving endpoint lies a silent, unguarded door. The endpoint Account-SavePreferences on ae.[redacted].com accepts POST requests to update a user's account preferences — yet it fails to enforce the very safeguard designed to protect it: the csrf_token. When the csrf_token parameter is stripped away entirely, the server raises no objection. It does not pause, does not verify, does not resist — it simply obeys. Compounding this weakness, the session cookie dwsid is configured with SameSite=None, stripping away the browser's last line of defense against cross-origin requests riding on an authenticated session. The result is a textbook Cross-Site Request Forgery: an attacker can craft a malicious page that, the moment a logged-in victim visits it, silently forges a request on their behalf — rewriting their account preferences without their knowledge, consent, or any visible sign of compromise. No sophisticated exploit chain is required; only a single click, or even just a page load, is enough to turn trust into a vulnerability.

PoC

A working proof-of-concept was hosted and demonstrated at: https://faizhidayatulloh.github.io/index.html. The PoC page contains an auto-submitting HTML form targeting: POST https://ae.[redacted].com/on/demandware.store/Sites-[redacted]_AE-Site/en_AE/Account-SavePreferences.
Crucially, the form omits the csrf_token field entirely. When an authenticated victim visits the PoC page, their browser — carrying the dwsid session cookie due to its SameSite=None attribute — automatically transmits the forged request. The server, expecting no token verification, processes it as legitimate, and the victim's account preferences are altered without their awareness.

Impact

An attacker can manipulate a victim's account preferences at will, purely through social engineering (e.g., luring the victim to a malicious link), with no interaction beyond a page visit required.

Summary

Somewhere between the user's browser and the origin server sits a cache — meant to serve static, harmless content faster. But on ae.[redacted].com, that cache was blind to context. It couldn't tell the difference between a public search results page and a page silently embedding a logged-in user's private data. The /en/search endpoint, when hit with an authenticated session and an arbitrary q parameter, doesn't just return search results — it renders personal account details directly into the page's script elements: email address, phone number, user ID, first name, and more. Under normal circumstances, this would remain confined to the victim's own session. But because the response to this URL gets cached — indexed by a query string an attacker fully controls — that private data becomes a hostage of the cache itself.

Step to Reproduce

• Craft a unique, never-before-used value for the q parameter to guarantee the request has not already been cached by another user: https://ae.[redacted].com/en/search?q=
• Send this crafted URL to the victim, ensuring they are logged into their account, and get them to open it in their browser.
• Once the victim's request has populated the cache, retrieve the same URL — either unauthenticated, via curl, or from an entirely different browser/session: curl "https://ae.[redacted].com/en/search?q=" | grep -i "Email"
• Observe that the response returned is the cached version originally generated for the victim — exposing their email, phone number, user ID, first name, and other sensitive account details embedded within the page's script elements.

Impact

Sensitive personally identifiable information (PII) — including email addresses, phone numbers, user IDs, and names — can be exposed to unauthenticated third parties through cache poisoning driven by attacker-controlled query parameters. This enables large-scale, low-effort harvesting of victim data simply by distributing uniquely crafted links and later scraping the resulting cached responses.

Remediation

• Exclude authenticated, user-specific responses from being cached — ensure Cache-Control: private, no-store (or equivalent) is applied to any response containing personalized data.
• Normalize or strip cache keys so that arbitrary query parameters (like q) cannot be used to create unique, cacheable variants of pages containing sensitive content.
• Ensure the caching layer (CDN/reverse proxy) is configured to respect Vary headers and cache-control directives on a per-user basis, rather than caching indiscriminately by URL alone.