A detailed description of WEB cache spoofing attack Technology

Have you ever thought that you only need to visit such as: https://www.paypal.com/myaccount/home/stylesheet.css or https://www.paypal.com/myaccount/settings/ Notifications/logo.png such a link could reveal your sensitive data and even allow the attacker to control your account?

Web cache spoofing is a new web attack vector, and the advent of this attack technology poses a risk to a variety of Web caching technologies and FRAMEWORKS.

A little introduction to Web caching and server response

Many web sites tend to use Web caching features (for example, through a cdn, a load balancer, or a simple reverse proxy). The purpose of using the Web Caching feature is Simple: store those files that are frequently retrieved to reduce the latency of the Web server Response.

Let's look at an example of a network Cache. Web site http://www.example.com is configured with a reverse proxy as a web Cache. Dynamic Web pages that are stored on the server and need to return user personal content (such as Http://www.example.com/home.php) must be created dynamically by different users, because each User's data is Different. This data, or at least this part of its personalization, is not cached.

More reasonable and common cache content is static or public files: style sheets (css), scripts (js), text files (txt), images (png,bmp,gif), etc., in the normal consciousness of most people, these files usually do not contain any sensitive information of the User. In addition, in articles on best practices for Web cache configuration, It is suggested that all exposed static files should be cached and their HTTP cache header information Ignored.

2. The network cache spoofing attack relies on the browser and Web server response, which is similar to RPO attacks, and the following two articles explain the RPO attacks.

http://www.thespanner.co.uk/2014/03/21/rpo/http://blog.innerht.ml/rpo-gadgets/ 

So what happens when I visit a URL like http://www.example.com/home.php/non-existent.css? (translator note: that is, after the http://www.example.com/home.php with the cached file type, the filename can be Non-existent)

The browser issues a GET request for the Url. The interesting thing is the response from the server-how will the server interpret the requested url? Depending on the Server's Web caching technology and configuration (the URL may have a slightly different structure for different servers), the server returns the contents of the Http://www.example.com/home.php. yes, the URL of the browser address bar is still http://www.example.com/home.php/non-existent.css. The HTTP header information is the same as the header information for direct access to http://www.example.com/home.php: the cache header information is the same as the content type (in this case, text/html).

If we visit http://www.example.com/home.php/non-existent.css, what happens, notice that the network cache of the static file has been set on the proxy server. Does the server ignore the cache headers for such files? Let's examine the process:

1. Browser request http://www.example.com/home.php/non-existent.css.  2. The server returns http://www.example.com/home.php content, most likely using an HTTP cache header that identifies not caching this Page.  3. The request should be requested through the proxy server.  4. The proxy server discovered that the File's extension is css.  5. In the cache directory, the proxy server creates a directory named home.php and caches the Imposter's "css" files (nonexistent css files).

Exploit exploits

If an attacker lures a logged-in user to access http://www.example.com/home.php/logo.png, the Web page (the page containing the User's personal Information) is cached on the cache server, so that the cached personal information is publicly accessible. If the HTTP principal information in the response contains (for some reason) a session identifier, a security issue or a csrf token, it may get worse. At such times, all attackers will access the cached pages themselves and then expose the cached User's privacy Data.

An interesting little thing.

typically, you do not need to authenticate to access the public static files of the site Cache. therefore, the cached files are public and accessible--no authentication is Required.

Conditions

therefore, basically, Two conditions are required to confirm that the Web site has this vulnerability:

1 . The Web caching feature determines whether the cache is cached by judging the extension of the Web application URL file, and ignores any cache header identity information in HTTP.  2. When you visit a webpage such as http://www.example.com/home.php/non-existent.css, The Web server will return the contents of the "home.php" url. 

Mitigation measures

1. Configure the caching mechanism of the cache file to be cached only if the HTTP cache header of the cache file is Allowed. This is the fundamental solution to this problem.

2. If the cache component provides the Content-type option, configure the cache component to be cached by the File's content Type.

3. Configure the Web server so that for pages such as http://www.example.com/home.php/non-existent.css, the Web server does not return the contents of the URL with "home.php". instead, the server should respond to requests for these URLs with 404 or 302来.

Web cache spoofing in the PayPal Web site-vulnerability disclosure

PayPal is vulnerable to network cache spoofing attacks. The vulnerability has now been fixed and publicly disclosed.

User information that could potentially be compromised by exploiting this vulnerability:

User's first and last name account balance last four credit card digital transaction data passport number email address Home Address Phone Number Vulnerability page contains any additional information

Some examples of vulnerability pages:

Https://www.paypal.com/myaccount/home/attack.csshttps://www.paypal.com/ Myaccount/settings/notifications/attack.csshttps://history.paypal.com/cgi-bin/webscr/ Attack.css?cmd=_history-details

Here are the various static file extensions (more than 40) that can be used to cache pages on the PayPal website:

aif,aiff,au,avi,bin,bmp,cab,carb,cct,cdf,class, css,doc,dcr,dtd,gcf,gff,gif,grv,hdml,hqx,ico,ini,jpeg, jpg, Js,mov,mp3,nc,pct,ppc,pws,swa,swf,txt,vbs,w32,wav,wbmp,wml,wmlc,wmls,wmlsc,xsd,zip

Cache Expiration

I tested the time that the cache file Expires. It appears that after being visited once (the first time), the file is cached for approximately 5 Hours. If accessed again during that period, the expiration time is Extended. obviously, This long period of time is enough to allow an attacker to "capture" the cache file before it expires, and to get the User's privacy information that he can expose when creating the cache file by constantly monitoring the url.

Web Cache Spoofing Attack technology detailed