by @bo0om, Wallarm Research
Caching is a great technology practice. It makes life better for everybody — clients get the data faster, servers expend fewer resources and so on. There is even a whole CDN industry that was built to deliver caching as a service.
There are many examples of caching configuration and tuning, but what I would like to talk about today are possible vulnerabilities in the caching techniques and methodology.
Some environments are configured in such a way that static files are cached based on their extensions. For examples, such files as css or js are cached.
Omer Gil in his blog describes the behavior where a web application, that initially sends a “200” OK response to a non-existing URL, than adding a static file extension to it (e.g. css) causes the page to get cached and makes it available to an anonymous user (attacker). More details about this hack are available in Omer’s blog.
Specifics of some web applications
Many sites are designed to insert the current domain name into the page. In the example of nginx server, it is sufficient for the following configuration fragment to be present:
server_name _; // accept any domain name
As long as the web application uses
$_SERVER[‘HTTP_HOST’] or something similar
When loading the page
mysite/index.php, the following code shows up:
At the same time, if one opens an HTTP request with one’s own Host header
GET /index.php HTTP/1.1
the code on the page changes:
If we were to change the domain name, the paths for loading resources and links to other pages have also changed. You’ve probably encountered such web sites, but understand, that it is impossible to send a link with one’s own Host header.
But is it really impossible?
A word about caching
Caching can be classified into several distinct categories:
Caching files without parameters
Caching with parameters ignored
A cache request will return:
Caching of each unique URL
Each unique URL will be cached separately
This is why some resources cache the first call to a page if this is the first time these parameters are showing up.
The idea here is to replace the Host header, creating a new unique URL that didn’t exist in a web app up to now.
GET /?MyUniqParam=test1337 HTTP/1.1
If such a URL ends up in the cache (not an uncommon occasion), we will be able to load our own java script from a resource we control.
By sending a URL
https://mysite/?MyUniqParam=test1337, we enable ourselves to execute an XSS attack, since the page has already cached our domain.
A couple more tricks
Another way to send a substitute header can be the following request:
If user data on the page do not allow the attack to be executed, we can try to modify the header.
For starters, we can try to execute a classic HTML injection by sending a known XSS vector in the header.
There is also another trick. Some web servers ignore the content of a header Host after the “
:” sign, which can also be present in the page content.
To take advantage of this, try the following request:
If these symbols do get filtered, try adding “
The final URL that gets put together will leave out some data — mysite will be treated as login info for the basic authentication, while the end of the request will include “evil”
Yet another trick to try is to append your own data to the end after a space:
Host: mysite “><xss>
In some cases, headers X-Forwarded-Host and Forwarded can overwrite the current value of Host. Headers can be simply added alongside the legitimate ones:
GET /?myparam=test HTTP/1.1
Header Forwarded looks slightly different, but works in the same way:
GET /?myparam=test HTTP/1.1
If caching is configured based on certain folders or file formats, it may be possible to create an exploit by creating a unique link not to the parameters on the page, but by adding a static extensions, such as js or css. Or you can try to get to the directories that may have been configured for aggressive caching, such as
In summary — most caching is useful, but there can still be problems. In addition to the Host header, an exploit can be put together by using other data that end up on the page, for example, User-agent or Referer. Because of the way web applications work, in many cases it is possible to poison the cache and, consequently, execute an attack. It’s worth trying out to understand better.