What is Web Cache Poisoning?
Web Cache Poisoning; Its Turkish equivalent is web cache poisoning. It is a type of attack that allows malicious code to be run by modifying web caches.
This type of attack is a type of attack that we encounter frequently in penetration tests.
What is Cache?
When we first open an application, all the data loaded is actually loaded into the cache, and then when we open the site for the second time, it appears quickly. This is what the cache actually does.
The cache stores our data and predicts the actions we will take next, presenting it before we take any action.
It waits for the requests made by the client to arrive, and then copies and saves the responses to these incoming requests.
Cache Keys
When a cache receives a request from the other party, it checks whether a copy of this request already exists. If it finds a copy, it continues with the copy and returns it to the user. If it cannot be found, it copies the request and makes the process easier to avoid doing the same thing in subsequent requests.
In fact, the cache does not compare the byte difference between requests in this case. It compares the "Host" and "Path" sections in the requests. In fact, when we enter with a different "User-Agent", that is, browser information, different data may be encountered.
The cache looks after the parts given in the example below.
Web Cache Poisoning Vulnerability Exploit Example
We will solve the exploitation example of this vulnerability, which we encounter frequently in penetration tests.
You can find our example on the PortSwigger site under the title "Web Cache Poisoning".
When we read the question, it says that a person is constantly browsing the home page and we are asked to run the "alert(document.cookie)" script on the other side.
We start our lab environment by saying “Access the lab”.
I went to the home page and activated "Intercept" with my "Burp Suite" tool, then added it to the "Repeater" section. After sending, I sent the request once and in the outgoing “Response” section, the “X-Cache: miss” section means that there is a “Web Cache” here.
When we send the same request once again, we can see that it returns a "hit".
I edited the path part and sent it again and it came back as "Miss".
In our next request, when we look at whether we can type any website in the "X-Forwarded-Host" section and print it to the other party, we see that it is returned within the script in the "Response" section.
This is how we make our settings by going to the "Exploit Server" section via Portswigger.
We write “resources/js/trecking.js” in the File section and “alert(document.cookie)” in the Body section. 
After selecting Store and continuing, we copy and paste the “Exploit Server” URL into the “X-Forwarded-Host” section and delete the change we made in the Path section.
When we clicked send and sent our request, we had the other party write “document.cookie” and solved our problem.
