InfoSec Brothers
Jun 26, 2019 · 4 min read

Sensitive Information Disclosure: Web Cache Deception Attack

Dear infosec community,

Great to see you back!!!

Thank you so much for sharing my last few write-ups on Twitter, LinkedIn and even on Facebook! Because of your encouragement and enormous support, I was able to see statistics of my story readers going high. This is huge for me!!!

In this write-up, I am going to explain to you guys another attack scenario known as “Web Cache Deception Attack”. Let’s understand it briefly.

Web Cache :

Did it ever occur to you that when you send the request to access some files such as .css, .js, .jpg and .txt sometimes, you get the response from the web server very quickly as compare to the requests you send in order to retrieve other data? Yes, if you have noticed, it happens. It happens because of the concept known as Cache. When we send the request, the server will categories the requests in two ways (in this context), request to access dynamic content and request to access static content. The files that I mentioned earlier comes under the category of static content. Websites often tend to use web cache functionality (for example over a CDN, a load balancer, or simply a reverse proxy). The purpose is simple: store files that are often retrieved such as static data files, to reduce latency from the web server.

Let’s understand what happens behind the wall in the eyesight of spitfire.

Consider a website, “” is hosted behind the CDN, a load balancer or a reverse proxy. A user sends the request to access the home page of a website after login. A user sent a request “”. A web server sends the response back to the user with the content that he/she gets after authentication. A user sends another request like, “” and the server responds back. However, when the server sends back this request, the reverse proxy (deployed between the user and the web server) stores that data in its cache considering it as static content. When next time a user requests abcd.css file, reverse proxy will not send that request to the web server, instead, it will serve the user with the data that it had stored in its cache. Thus, the request for static data is not reaching the web server again. So, to sum up, given below is the actual scenario,

Image for post
Image for post

I hope, I was able to explain the concept of reverse proxy or cache to all of you very briefly and very well. If you have understood this, let’s move ahead and I will explain to you the advantage the attacker takes keeping the concept of Web Cache in the mind.

Web Cache Deception:

As the attacker knows the website is hosted behind some kind of proxies, CDNs or load balancer. The attacker will access “”. After the authentication, the attacker is getting the next page and that is “”. The attacker will send a URL that will look like request to access the static web pages those are available to access to anyone even without authentication. So the crafted URL by the attacker is “”. However, as there is no such web page, the web server responds back with the data for “”. But the URL in the browser looks like “”. So, in this scenario, the attacker is getting data for “http//” even he has requested “”. This is the best case scenario to test the web cache deception attack. Now, when the request from an unauthenticated source will go, the proxy server will not send that request to the Web server, instead, the proxy server will respond back with the data that must be seen only by the authenticated user. Given below is the scenario that is described by Omar Gil while describing his bug bounty PayPal Engineering.

Image for post
Image for post
Condition to test Web Cache Deception

Web Cache Deception Attack by Spitfire

Please watch below video POC,

After reporting above bug to Intuit, Intuit QuickBooks, I got the Hall of Fame from them.

Image for post
Image for post
Wasim Shaikh Will be here as long as the Intuit is there!

I hope I have explained to you the concept of cache, how to find the cache deception vulnerability. Following are widely accepted suggestions to prevent or to fix the Web Cache Deception Vulnerability.


  1. Configure the cache mechanism to cache files only if their HTTP caching headers allow. That will solve the root cause of this issue.

To have a deep understanding of this attack scenario, please visit the following blog by Omar Gil.


To know about my upcoming write-ups and to read them, follow me on Medium and Twitter:

Thank you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store