Lab: Cache key injection

Solving this lab requires an understanding of several other web vulnerabilities. If you're still having trouble solving it after several hours, we recommend completing all other topics on the Web Security Academy first.

Remember that the injected origin header must be lowercase, to comply with the HTTP/2 specification. For more information on how Burp Suite supports HTTP/2-based testing, see Working with HTTP/2 in Burp Suite.

1. Observe that the redirect at /login excludes the parameter utm_content from the cache key using a flawed regex. This allows you append arbitrary unkeyed content to the lang parameter:

   /login?lang=en?utm_content=anything
2. Observe that the page at /login/ has an import from /js/localize.js. This is vulnerable to client-side parameter pollution via the lang parameter because it doesn't URL-encode the value.
3. Observe that the login page references an endpoint at /js/localize.js that is vulnerable to response header injection via the Origin request header, provided the cors parameter is set to 1.
4. Use the Pragma: x-get-cache-key header to identify that the server is vulnerable to cache key injection, meaning the header injection can be triggered via a crafted URL.

5. Combine these four behaviors by poisoning the cache with following two requests:

   GET /js/localize.js?lang=en?utm_content=z&cors=1&x=1 HTTP/2 Origin: x%0d%0aContent-Length:%208%0d%0a%0d%0aalert(1)$$$$ GET /login?lang=en?utm_content=x%26cors=1%26x=1$$origin=x%250d%250aContent-Length:%208%250d%250a%250d%250aalert(1)$$%23 HTTP/2

   Note that the injected origin header is lower case to comply with the HTTP/2 specification.

6. This will poison /login?lang=en such that it redirects to a login page with a poisoned localization import that executes alert(1), solving the lab.