Web Cache Vulnerability Scanner (WCVS) is an open source standalone CLI web cache poisoning vulnerability scanner. We just released the stable version of WCVS to the public. As already announced in our previous blog post about web cache poisoning, WCVS enables users to easily and thoroughly scan their applications for web cache poisoning. In this blog post we will introduce the main features of WCVS.
Various Web Cache Poisoning Techniques
WCVS supports a total of nine different web cache poisoning techniques, which are based on scientific papers and articles published by security experts.
- Unkeyed header poisoning [1] [2]
- Unkeyed parameter poisoning [1]
- Parameter cloaking [3]
- Fat GET [3]
- HTTP request smuggling [4]
- HTTP response splitting [5]
- HTTP header oversize [6]
- HTTP meta character [6]
- HTTP method override [6]
Bulk Scanning and Crawler
WCVS was built with bulk scanning in mind from the beginning. The excellent multithreading possibilities of the programming language Go ensure that processing time is not a limiting factor. The scanner takes either a single or multiple URLs and IP addresses, which are scanned one after another. A customizable crawler can analyze the HTTP responses in order to find even more URLs to scan. By default the crawler is disabled; however if it is enabled it can be customized to suit your needs. Possible customizations include to skip certain URLs, to only add URLs which contain a specific string, or to limit the maximum number of additional URLs.
Customization for Your Application
Before conducting tests for web cache poisoning, WCVS already does some automatic adjustments to be properly configured for the current website. For this purpose it sends a few requests to analyze the caching behavior of your application. For example, if no cache could be detected, WCVS - by default - does not conduct any tests and, thus, skips the website. If a cache is detected and its behavior was analyzed successfully, some parameters are tweaked in order to test efficiently. Besides these automatic adjustments WCVS is highly customizable thanks to its dozen command line flags. Some possible customizations are the following:
Custom Headers, Cookies, Parameters, and More
For many tests, cookies are needed as websites rely on them to function properly or for successful session management. The same can apply to headers, parameters, or any other part of the HTTP request. The HTTP method, headers, cookies, parameters, and the body can be set to specific values.
Custom Wordlists
WCVS needs two wordlists in order to test for most web cache poisoning techniques - one wordlist for header names and one for parameter names. Two default wordlists are provided with the scanner. These are currently a slightly modified version of the headers and params wordlist generated by the security researcher James Kettle. While these two wordlists contain the names of many of the most commonly used header and parameter names, this might not be sufficient for some websites. Therefore, custom wordlists can be used instead. They can either be based on the default wordlists or be fully custom-tailored ones. This ensures the flexibility that every supported header or parameter of an application can be tested for web cache poisoning.
Rate Limiting
By default, WCVS is not limited on how many requests per second it sends, besides the 20 threads it is using during testing. While it is possible to increase or decrease the number of threads in order to also impact the amount of requests per second, this does not ensure complete control. Therefore, it is also possible to specify a maximum number of requests per second, which will not be exceeded by WCVS. This can be useful for multiple reasons. For example, too many requests per second can overload a server or the network or result in WCVS getting blocked by a web application firewall, which only allows a certain amount of requests per second.
Detailed JSON Reports
In order to quickly analyze or further process the results, WCVS generates a report in JSON format. Besides statistics, such as the duration of the whole scan and the configuration of the scan, it contains information about the tested websites. The most important information is whether a website was found to be vulnerable to web cache poisoning or if any error or unexpected behaviour was noticed. Furthermore, if a technique was successful the HTTP request - which poisoned the cache - and the corresponding HTTP response are written to the report. Thus, it is possible to easily analyze and confirm the finding by manually sending a similarly manipulated request.
{ "name": "Web_Cache_Vulnerability_Scanner", "version": "1.0.0", "foundVulnerabilities": true, "hasError": false, "errorMessages": null, "date": "2021-10-27_08-56-49", "duration": "30.387642061s", "command": "wcvs -u https://example.com/ -gr", "config": {[...]}, "websites": [ { "url": "https://example.com/", "isVulnerable": true, "hasError": false, "errorMessages": null, "results": [ [...] { "technique": "Forward/Host Headers", "hasError": false, "errorMessages": null, "isVulnerable": true, "requests": [ { "reason": "Location header contains poison value 727356299485", "request": "GET /?cb=595559747024 HTTP/1.1\r\nHost: example.com\r\nUser-Agent: WebCacheVulnerabilityScanner v1.0.0\r\nCookie: session=P6PDVZj5WYSLTYZEjjvD8msv6Q5BlTRr\r\nX-Forwarded-Host: 727356299485\r\nX-Forwarded-Scheme: nothttps\r\nAccept-Encoding: gzip\r\n\r\n", "response": "HTTP/2.0 302 Found\r\nAge: 0\r\nCache-Control: max-age=30\r\nLocation: https://727356299485/?cb=595559747024\r\nX-Cache: miss\r\nContent-Length: 0\r\n\r\n" } ] },
Listing 1: Example report of Web Cache Vulnerability Scanner.
Where to Download and How to Use
WCVS can be downloaded from the releases page of its official Github repository. There are precompiled binaries for different operating systems provided. Each binary comes archived with the two default wordlists. After extracting the binary and the default wordlists WCVS is ready to test your application.
The WCVS Github repository contains explanations and examples for the most common features. To simply test if WCVS runs properly, it can be executed with its default settings and only a single URL as command line flag:
wcvs -u https://example.com
Figure 1: Example output of Web Cache Vulnerability Scanner.
Do you think the tool described above is interesting and would you like to use it in a penetration test yourself? Have a look at our career page and see if there is an interesting job offer for you.
[1] J. Kettle. Practical Web Cache Poisoning, 2021. URL: https://portswigger.net/research/practical-web-cache-poisoning.
[2] J. Kettle. Responsible denial of service with web cache poisoning, 2019. URL: https://portswigger.net/research/responsible-denial-of-service-with-web-cache-poisoning.
[3] J. Kettle. Web Cache Entanglement: Novel Pathways to Poisoning, 2020. URL: https://portswigger.net/research/web-cache-entanglement.
[4] C. Linhart et. al. HTTP Request Smuggling, 2005. URL: https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf.
[5] A. Klein. “Divide and Conquer” - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics, 2004. URL: https://dl.packetstormsecurity.net/papers/general/whitepaper_httpresponse.pdf
[6] H.V. Nguyen et. al. CPDoS: Cache Poisoned Denial of Service, 2019. URL: https://cpdos.org/.
Our Experts Develop the Optimal Solution for You
Web Caches – Cross-Site Scripting (XXS) – Web Security
Are you using web caches in your web application and want to make sure they are used in a secure way? Or do you want to ensure your application's users and data is protected against other threats?
We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:
IT Security Consulting | Training | Penetration Tests
Don't hesitate and find your way to secure web applications with us. We look forward to supporting you with your projects.
Your Contact for Web Security
Prof. Dr. Marcus Niemietz
marcus.niemietz@hackmanit.de