Hey Fam! Hope you and your family are doing well amid this pandemic. This story is about the approach I took to find My 1st critical web cache poisoning in an external Program.

So let’s begin:

Target is an External program. So, let’s call it redacted.com

First Let’s Start With web cache poisoning Vulnerability and how it arises?

Web cache poisoning is a sophisticated technique in which an attacker wants to take advantage of a web server’s and cache’s actions to serve a malicious HTTP response to other users.

There are two steps to web cache poisoning. To begin, the attacker must figure out how to get a potentially dangerous payload response from the backend server. They must cache their response and serve it only to the intended victims after they have succeeded.

An infected web cache has the ability to be a destructive means of disseminating a series of attacks, involving XSS, DOS, JavaScript injection, open redirection, and so on.

Validating Web Cache Poisoning:

1. Finds the weak service code that allows them to stuff a lot of headers into the HTTP header area.
2. The cache server is forced to flush its actual cache information, which we want the servers to cache.
3. Sends a specially constructed request to the server, which will be cached.
4. The next request is sent. The response to this request will be the previously injected content stored in the cache.

Headers That Can Be Used To Cache :

X-Forwarded-Host: your-hackers-site.com

X-Host: your-hackers-site.com

Forwarded-Server: your-hackers-site.com

Here the Method Was that simple, I used Param Miner to identify hidden, unlinked parameters. It’s particularly useful for finding web cache poisoning vulnerabilities.

To use it, right-click on a request in Burp and click “Guess (cookies|headers|params)”. If you’re using Burp Suite Pro, identified parameters will be reported as scanner issues. If not, you can find them listed under Extender->Extensions->Param Miner->Output

So Here I was able to identify a Secret uncached input later I used it to check whether the Vulnerability exists or not.

I had to confirm it and yes the vulnerability was present, Next, I wanted to build an impact such as escalating it to XSS, URL Redirect, and so on. Later I found out that the poisoning was taking place in the Profile section where I could easily cache the request by using my server to get the response Here I used BurpCollaborator, Or we can use interactsh freely open-source Tool which is provided by Project Discovery Team to get the Interaction support.

If the user browses through the cached section, And it was successful I was able to get the Critical Information such as their Session, Cookies, PII.

If a specially crafted response is cached by a web cache used by several users or even a single user’s browser cache, the impact of the response may well be increased. Unless an answer is stored in a shared site cache, such as those located in proxy servers, all users of that cache will receive the malicious content just before cache entry is purged. I believe it is possible to escalate beyond Stored XSS.