exploiting-cookie-based-vulnerabilities

Set a cookie from a controlled subdomain with a leading Unicode whitespace code point (e.g., U+2000) before the __Host- name. Browsers store it since the name does not literally start with the prefix, but backends that trim whitespace normalize it to the protected name and adopt the attacker value.

Use padbuster against the target with the encrypted cookie and block size to decrypt it via CBC padding oracle errors. Then re-run padbuster with a -plaintext argument like user=administrator to forge a valid admin cookie the application accepts.

A cookie sandwich uses $Version=1 legacy parsing plus open and close quoted cookies to trap an HttpOnly cookie inside a reflected value. When the server reflects the attacker-controlled cookie, the victim's HttpOnly session value is exfiltrated within it.

Cookie tossing works when you control or find XSS on a subdomain and the parent application reads cookies scoped with Domain set to the parent. It fails when session cookies use the __Host- prefix correctly, since that forbids Domain attributes and requires Path=/.

The workflow uses Burp Suite with the CookiePrefixBypass bambda for raw header crafting, padbuster for padding-oracle attacks, CyberChef for Base64/hex decoding, and browser devtools with two profiles for cross-context cookie testing.

It is not applicable without explicit authorization covering session and authentication testing, or when the application uses server-side sessions with random IDs and correct __Host- prefixes. In those cases there is no client-side cookie surface to attack.