Exploiting web cache poisoning

Web cache poisoning design flaws

Notes based on content from here

Use Param miner to find the headers that change output, there are lots (old school use of TRACE might also allow some hidden ones added automatically to be found)

Be aware that some behaviour might require two headers to be set, notice the interaction between them

While working out pocs, change keyed input such as the URL to ensure you dont poison others (e.g. add ?x=1), but be aware that some apps wont consider query strings as cachebusters, you might need to modify other keyed fields such as the Accept header, Accept-Encoding, Cookie, User-Agent, Origin etc, there are various options in Param miner for this

Once you can affect the page content being delivered, now you want to get it into the cache

Essentially, repeat the request until you see cache: hit

What might stop it from being cached?

• The fields in vary
• If a cookie is set, the request wont be cached (try having the cookie set yourself)

Common headings:

• X-Forwarded-Host
• X-Host
• X-Forwarded-Proto
• X-Forwarded-Scheme
• X-Forwarded-Host
• X-Original-URL

Other stuff to examine:

• Host header duplicated or duplicated but with one using a leading space
• Cookies, are they in the cache key
• Port number in host
• try duplicates

Web cache implementation flaws

Notes based on content from here

This can be very cache specific and requires manual investigation

Bulk scan in param miner will identify some of these cache specific ones

Identify a cache oracle - something that tells you if the requests you send are being cached

This will respond with a header tell you the cache key on Akamai

Pragma: akamai-x-get-cache-key

This is a different one:

Pragma: x-get-cache-key

See if there is any processing done on the keyed input to normalise it (might allow you to send attacks in cache key and yet still have them cached for normal requests)

This might be excluding a port number from the Host header, not including query strings in URL keying, etc

Dont forget to look for Javascript callback URLs, or any other dynamically generated content based on URL parameters, e.g. in CSS (for data exfil)

Query parameters that might not be keyed (param miner can find them)

• utm_medium
• utm_source
• utm_campaign
• utm_term
• utm_content
• utm_name

Fat GETs are where you can set a parameter value in the GET body (when the backend server is not set for a specific method). The cache might only look at the key in the URL and the backend might look at the body param

URL normalisation might mean that XSS that relies on unencoded URLs being sent by a browser (e.g. in the URL path) become exploitable because the cache might key these the same as the URL encoded version, allowing the unencoded version to be returned. e.g. the encoded version of the below

/<script>alert(1)</script>

Cache key injection involves manipulating the process by which cache keys are created by combining other values. You can perhaps induce a victim into visiting a cached entry you have created by doing thigns such as manipulating the URL to refer to that entry by injecting the additional cache key parameters into it

For example the cache key seperates values with ‘__’ and includes the Origin header which you can reflect data with. You might then be able to redirect users to that cached response by doing:

http://site/url__Origin: badness

The cache keys will not always be clearnly implemented, they can have flawed logic, matching, etc, so unusual input might allow additional data to be cached by doing things such as adding unkeyed params like:

http://site/url?param1=x?sneaky_param=badstuff

For dual caches, param miner can add a dynamic cache buster to each request made by burp, which can be helpful in troubleshooting stuff, e.g. bypassing one cache and focusing on the other