Web
cache deception is a new web attack vector that puts various technologies and
frameworks at risk.

A few words about
caching and reactions

1. 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, to reduce latency from the web
server.

Let's
see an example of web cache. Website http://www.example.com
is configured to go through a reverse proxy. A dynamic page that is stored on
the server and returns personal content of users, such as http://www.example.com/home.php, will
have to create it dynamically per user, since the data is different for each
user. This kind of data, or at least its personalized parts, isn't cached.

What's
more reasonable and common to cache are static, public files: style sheets (css),
scripts (js), text files (txt), images (png, bmp, gif), etc. This makes sense
because these files usually don't contain any sensitive information. In
addition, as can be found in various best practices articles about web cache
configuration, it's recommended to cache all static files that are meant to be
public, and disregard their HTTP caching headers.

Under the cache directory,
the proxy creates a directory named home.php, and caches the imposter
"CSS" file (non-existent.css) inside.

Oh.

Taking advantage of
it

An attacker who lures a logged-on user to access http://www.example.com/home.php/logo.png
will cause this page – containing the user's personal content – to be cached
and thus publicly-accessible. It could get even worse, if the body of the response
contains (for some reason) the session identifier, security answers or CSRF
tokens. All the attacker has to do now is to access this page on his own and
expose this data.

An anecdote

Usually websites don't require authentication to access
their public static files. Therefore, the cached files are publicly-accessible
– no authentication required.

Conditions

So basically, two conditions are required for this
vulnerability to exist:

Web cache functionality is set for the web application
to cache files by their extensions, disregarding any caching header.

Mitigation

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

If the cache component provides the option, configure it
to cache files by their content type.

Configure the web server so that for pages such as http://www.example.com/home.php/non-existent.css,
the web server doesn’t return the content of "home.php" with this
URL. Instead, for example, the server should respond with a 404 or 302
response.

Web Cache Deception
in PayPal – PII Exposure

PayPal was vulnerable to web cache deception. The vulnerability
is now fixed and was publicly disclosed.

I've measured the time taken for the cached files to
expire. It seems that after being accessed once (for the first time), a file is
cached for ~5 hours. If it's accessed again during that time, the expiration
time is extended. It's clear that this time period is more than enough for an
attacker to "catch" the cached file on time before it expires, and by
constantly monitoring this URL he can expose it as it's created.

User Hijacking via
Web Cache Deception

I found this vulnerability in additional applications, which
unfortunately cannot be disclosed to the public for different reasons (bummer,
had some nice videos for that). In these applications, it was possible to take
complete control over application users. This was possible because the
session ID or security answers to recover a user's password were included in
the HTML code of vulnerable pages. Big thanks to Sagi Cohen for the
assistance.

IIS Demo

In the video below, a website is hosted on two web servers
behind an IIS load balancer with Application Request Routing (ARR) installed.A
successful login redirects the users to the 'welcome.php' page, which contains
their personal content. The load balancer is configured to cache all CSS files,
and to disregard their caching headers.

An authenticated user accesses http://www.sampleapp.com/welcome.php/stylesheet.css.
The IIS load balancer refers to the 'welcome.php' page as a directory, creates it
in the cache directory, and caches 'stylsheet.css', which contains the user's
private content.