20 Feb, 2023

Web Cache Poisoning Attack

Vulnerability Assessment as a Service (VAaaS)

Tests systems and applications for vulnerabilities to address weaknesses.

The abbreviation for Web Cache Poisoning is WCP.

Web Cache Poisoning is a type of cyber attack that can have serious consequences for websites and their users. It occurs when an attacker exploits vulnerabilities in a web cache server to serve malicious content to unsuspecting users.

Web caches are used to store frequently accessed data on a web server, which can improve website performance and reduce the load on the server. However, when an attacker is able to manipulate the contents of a web cache, they can serve malicious content to users who request legitimate content from the cache.

To carry out a Web Cache Poisoning attack, the attacker sends specially crafted HTTP requests to the web server, which can cause the cache to store the attacker’s malicious content instead of the legitimate content. When a user requests the legitimate content, the cache returns the attacker’s malicious content instead, which can range from fake login pages to malware-infected files.

The consequences of a successful Web Cache Poisoning attack can be severe, ranging from the theft of sensitive data to the spread of malware or the compromise of a user’s system. Therefore, it is important for web server administrators to keep their software and security measures up to date to prevent this type of attack. Additionally, users should be aware of the risks of accessing web content through unsecured or untrusted sources, and should take measures to protect their own systems from such attacks.

Types of Web Cache Poisoning

There are several types of Web Cache Poisoning attacks that are known to cyber attackers. 

  1. Blind Web Cache Poisoning: In this type of attack, the attacker sends HTTP requests with specially crafted headers that force the web cache to store the attacker’s content. The attacker does not receive any response from the server, making it more difficult to detect the attack.

  2. Delayed Web Cache Poisoning: In this type of attack, the attacker sends HTTP requests that are designed to be cached for a longer period of time. This delay can make it more difficult for the cache to be updated with legitimate content, giving the attacker more time to serve malicious content.

  3. Header Injection Web Cache Poisoning: In this type of attack, the attacker injects malicious content into HTTP headers, which are then stored in the web cache. This allows the attacker to control the content that is served to users who request the legitimate content.

  4. Cross-Site Scripting (XSS) Web Cache Poisoning: In this type of attack, the attacker injects malicious JavaScript into a web page that is then stored in the web cache. This allows the attacker to execute code on the victim’s browser, which can lead to the theft of sensitive information or the compromise of their system.

  5. Content Spoofing Web Cache Poisoning: In this type of attack, the attacker spoofs the content stored in the web cache to serve malicious content to users. This can be used to trick users into disclosing sensitive information or downloading malware.

  6. Cache Deception Web Cache Poisoning: In this type of attack, the attacker creates a fake website that is designed to look like a legitimate website. The attacker then sends requests to the web cache, which stores the fake website instead of the legitimate one. This can be used to trick users into divulging sensitive information or downloading malware.

Examples of the requests that can be used to test Web Cache Poisoning

Burp Suite is a popular web application security testing tool that can be used to analyze and test for Web Cache Poisoning attacks. Some examples of different requests.

Example of a GET and POST requests

Example of a GET request:

A GET request is a type of HTTP request that retrieves data from a web server.

				
					GET /index.php?param=value HTTP/1.1
Host: example.com
				
			

n this example, the user is requesting a webpage called “index.php” with a parameter called “param” that has a value of “value”. This is a common type of GET request that is used to request specific content from a web server.

To carry out a Web Cache Poisoning attack using this type of request, the attacker could modify the HTTP headers in a way that causes the web cache to store their malicious content instead of the legitimate content. For example, the attacker could add a custom “If-None-Match” header that matches a fake ETag value, which would cause the web cache to serve their content instead of the legitimate content. This technique is known as ETag-based cache poisoning.

Example of a POST request:

A POST request is a type of HTTP request that submits data to a web server.

				
					POST /login.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the user is sending a POST request to a webpage called “login.php” with a username and password. This is a common type of request used for login pages and other forms that require user input.

To carry out a Web Cache Poisoning attack using this type of request, the attacker could modify the HTTP headers in a way that causes the web cache to store their malicious content instead of the legitimate content. For example, the attacker could add a custom “If-Modified-Since” header that contains a timestamp in the future, which would cause the web cache to serve their content instead of the legitimate content. This technique is known as time-based cache poisoning.

It is important to note that these are just two examples of how Web Cache Poisoning attacks could be carried out using HTTP requests. There are many other techniques that attackers can use to manipulate web caches, so it is important for web server administrators to be aware of the risks and take appropriate measures to protect against them.

Here are some examples of GET and POST requests in Burp Suite that demonstrate different types of Web Cache Poisoning attacks.

Blind Web Cache Poisoning:

				
					GET /index.html HTTP/1.1
Host: example.com
X-Poison: <script>alert('XSS')</script>
				
			
				
					GET /search.php?q=<script>alert('XSS')</script> HTTP/1.1
Host: example.com
				
			

In this example, the attacker sends a specially crafted GET request with a custom “X-Poison” header. The header is designed to be stored in the cache, and when other users request the same resource, the cache serves the attacker’s malicious content instead of the legitimate content.

				
					POST /login.php HTTP/1.1
Host: example.com
X-Poison: <script>alert('XSS')</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the attacker sends a specially crafted POST request with a custom “X-Poison” header. The header is designed to be stored in the cache, and when other users request the same resource, the cache serves the attacker’s malicious content instead of the legitimate content.

Delayed Web Cache Poisoning:

				
					GET /index.html HTTP/1.1
Host: example.com
Cache-Control: max-age=3600
				
			

In this example, the attacker sends a GET request with a custom “Cache-Control” header that tells the cache to store the content for a longer period of time. The attacker can then modify the legitimate content, and the cache will continue to serve the outdated, malicious content to users until the cache is refreshed.

				
					POST /login.php HTTP/1.1
Host: example.com
Cache-Control: max-age=3600
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the attacker sends a POST request with a custom “Cache-Control” header that tells the cache to store the content for a longer period of time. The attacker can then modify the legitimate content, and the cache will continue to serve the outdated, malicious content to users until the cache is refreshed.

Header Injection Web Cache Poisoning:

				
					GET /index.php HTTP/1.1
Host: example.com
User-Agent: <script>alert('XSS')</script>
				
			

In this example, the attacker is injecting malicious JavaScript code into the “User-Agent” header of the GET request. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the malicious code.:

				
					GET /index.php?page=<iframe src="https://malicious-site.com"></iframe> HTTP/1.1
Host: example.comaPOST /login.php HTTP/1.1
Host: example.com
User-Agent: <script>alert('XSS')</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the attacker sends a POST request with a custom “User-Agent” header that contains malicious JavaScript code. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the malicious JavaScript code.

Cross-Site Scripting (XSS) Web Cache Poisoning:

				
					GET /index.html HTTP/1.1
Host: example.com
Referer: http://attacker.com/?q=<script>alert('XSS')</script>
				
			

In this example, the attacker sends a GET request with a custom “Referer” header that contains a URL with a cross-site scripting payload. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the malicious payload.

				
					POST /login.php HTTP/1.1
Host: example.com
Referer: http://attacker.com/?q=<script>alert('XSS')</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the attacker sends a POST request with a custom “Referer” header that contains a URL with a cross-site scripting payload. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the malicious payload.

Content Spoofing Web Cache Poisoning:

				
					GET /index.html HTTP/1.1
Host: example.com
Accept-Language: <script>alert('XSS')</script>
				
			

In this example, the attacker sends a GET request with a custom “Accept-Language” header that spoofs the language of the user. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the spoofed language.

				
					POST /login.php HTTP/1.1
Host: example.com
Accept-Language: <script>alert('XSS')</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username=john&password=pass
				
			

In this example, the attacker sends a POST request with a custom “Accept-Language” header that spoofs the language of the user. The web server stores the malicious header in the cache, and when other users request the same resource, the cache serves the attacker’s content along with the spoofed language.

Cache Deception Web Cache Poisoning:

				
					GET /index.html HTTP/1.1
Host: attacker.com
				
			

In this example, the attacker creates a fake website that looks similar to a legitimate website. The attacker sends a GET request with a custom “Host” header that matches the fake website, and the web server stores the malicious header in the cache. When other users request the same resource, the cache serves the attacker’s content along with the fake Host header.

				
					POST /login.php HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

username
				
			

In this example, the attacker creates a fake website that looks similar to a legitimate website. The attacker sends a POST request with a custom “Host” header that matches the fake website, and the web server stores the malicious header in the cache. When other users request the same resource, the cache serves the attacker’s content along with the fake Host header.

Examples of Web Cache Poisoning exploitation

Web Cache Poisoning is a technique used by attackers to insert malicious content into a web cache.

Here are some examples of how web cache poisoning can be exploited:

  1. Stealing sensitive data: An attacker can exploit web cache poisoning to steal sensitive data such as login credentials or credit card information. By injecting malicious code into a web cache, the attacker can intercept and access this information.

  2. Session hijacking: Web cache poisoning can also be used to hijack user sessions. This involves tricking a user into clicking a link that leads to a poisoned cache. Once the user accesses the poisoned page, the attacker can steal their session token and impersonate them.

  3. Malware delivery: An attacker can use web cache poisoning to deliver malware to users. By injecting malicious code into a web cache, the attacker can deliver malware to any user who accesses the poisoned page.

  4. Phishing attacks: Web cache poisoning can be used in phishing attacks. An attacker can inject a phishing page into a web cache and then trick users into accessing it. This can lead to users unwittingly giving away their login credentials or other sensitive information.

  5. Content injection: An attacker can use web cache poisoning to inject content into a website. This can include fake news articles, advertisements, or other malicious content. This can be used to spread false information or to trick users into clicking on links that lead to malware or other attacks.

Privilege escalation techniques Web Cache Poisoning

Privilege escalation refers to the act of an attacker gaining higher levels of access to a system or application than they were originally authorized for. When it comes to web cache poisoning, there are several techniques that can be used to achieve privilege escalation.

  1. Cache Poisoning via HTTP Verb Tampering: This technique involves tampering with the HTTP verbs that are used in a request to the server. By changing the HTTP verb in a request, an attacker can trick the server into caching a response that is intended for a different user with higher privileges. For example, an attacker could use a PUT request to modify the contents of a page that is normally only editable by an admin user, thereby gaining admin-level privileges.

  2. Poisoning via Insecure Cache Key Generation: Some applications generate cache keys based on user input, which can be manipulated by an attacker. By crafting a specially formatted request, an attacker can poison the cache key, resulting in the server returning cached responses that are intended for a different user. This can allow an attacker to escalate their privileges by accessing pages or data that they were not authorized to access.

  3. Poisoning via HTTP Response Splitting: HTTP response splitting is a vulnerability that allows an attacker to inject additional headers into an HTTP response, which can be used to poison the cache. By injecting a specially crafted header into an HTTP response, an attacker can cause the server to cache a response that is intended for a different user with higher privileges.

  4. Poisoning via Parameter Pollution: This technique involves injecting additional parameters into a request that can be used to manipulate the cache key. By manipulating the cache key, an attacker can trick the server into returning cached responses that are intended for a different user with higher privileges.

  5. Poisoning via Bypassing Cache-Control: Some applications use the Cache-Control header to prevent caching of sensitive data. However, if an attacker can bypass this header, they can cause the server to cache sensitive data that can be used to escalate their privileges.

General methodology and checklist for testing Web Cache Poisoning

Testing for web cache poisoning involves a systematic approach to identify vulnerabilities and potential attack vectors. Here is a general methodology and checklist for testing web cache poisoning:

  1. Identify the target application: Determine the application that will be tested for web cache poisoning. This can include websites, web applications, and APIs.

  2. Identify the caching mechanism: Identify the caching mechanism used by the target application. This can include browser caching, proxy caching, and server-side caching.

  3. Identify potential attack vectors: Identify the potential attack vectors for web cache poisoning, such as HTTP verb tampering, insecure cache key generation, HTTP response splitting, parameter pollution, and bypassing Cache-Control headers.

  4. Test caching behavior: Test the caching behavior of the application by sending requests with different parameters and headers. This can include testing caching of dynamic content, caching of private data, and caching of error messages.

  5. Test for cache poisoning: Test for cache poisoning by injecting payloads into requests and responses. This can include injecting payloads into HTTP headers, request parameters, and response bodies.

  6. Analyze the cache: Analyze the cache to determine whether the injected payloads have been cached. This can include using tools such as Burp Suite or Fiddler to view the cache contents.

  7. Exploit the vulnerability: Exploit the vulnerability by using the injected payloads to escalate privileges, steal sensitive data, or deliver malware.

  8. Validate the results: Validate the results of the testing by verifying that the attack was successful, and that the vulnerabilities have been properly remediated.

Here is a checklist that can be used to guide testing for web cache poisoning:

Identify the target application and caching mechanism

Identify the potential attack vectors

Test caching behavior

Test for cache poisoning

Analyze the cache

Exploit the vulnerability

Validate the results

Document the findings and report them to the relevant parties

It is important to note that testing for web cache poisoning should only be performed on systems and applications that you have permission to test. Unauthorized testing can lead to legal and ethical issues.

Tools set for exploiting Web Cache Poisoning

Manual Tools:

  1. Burp Suite: Burp Suite is a popular tool for web application security testing, including web cache poisoning. It allows for manual testing of web cache poisoning vulnerabilities by intercepting and modifying HTTP requests and responses.

  2. OWASP ZAP: OWASP ZAP is an open-source web application security scanner that includes a range of features for identifying web cache poisoning vulnerabilities, including fuzzing and parameter manipulation.

  3. Fiddler: Fiddler is a web debugging proxy that can be used for testing web cache poisoning. It allows for manual testing of web cache poisoning vulnerabilities by intercepting and modifying HTTP requests and responses.

  4. Postman: Postman is a popular API testing tool that can be used to manually test for web cache poisoning vulnerabilities. It allows for the creation of custom HTTP requests and the modification of request parameters and headers.

  5. cURL: cURL is a command-line tool that can be used to manually test for web cache poisoning vulnerabilities. It allows for the creation of custom HTTP requests and the modification of request parameters and headers.

Automated Tools:

  1. Cache Poisoner: Cache Poisoner is an open-source tool that automates the process of testing for web cache poisoning vulnerabilities. It can be used to automatically inject payloads into HTTP requests and responses and analyze the cache contents.

  2. CacheKiller: CacheKiller is a browser extension that can be used to automatically clear browser caches and disable caching to prevent web cache poisoning attacks.

  3. Sniper: Sniper is an automated web application testing tool that includes a range of features for identifying web cache poisoning vulnerabilities, including cache poisoning via parameter pollution and HTTP response splitting.

  4. Nuclei: Nuclei is a powerful tool for web application scanning that includes a range of built-in templates for identifying web cache poisoning vulnerabilities.

  5. Arachni: Arachni is a web application security scanner that includes a range of features for identifying web cache poisoning vulnerabilities, including parameter pollution and HTTP response splitting.

Browser Plugins:

  1. Tamper Chrome: Tamper Chrome is a browser extension that can be used to manually test for web cache poisoning vulnerabilities. It allows for the interception and modification of HTTP requests and responses.

  2. Web Developer: Web Developer is a browser extension that includes a range of features for testing web cache poisoning vulnerabilities, including the ability to clear browser caches and disable caching.

  3. HackBar: HackBar is a browser extension that can be used to manually test for web cache poisoning vulnerabilities. It allows for the interception and modification of HTTP requests and responses.

  4. Wappalyzer: Wappalyzer is a browser extension that can be used to identify the caching mechanism used by a web application, which can be useful in identifying potential attack vectors for web cache poisoning.

Testing Frameworks:

  1. OWASP Amass: OWASP Amass is a testing framework that includes a range of tools for identifying web cache poisoning vulnerabilities, including subdomain discovery, port scanning, and HTTP request analysis.

  2. OWASP Nettacker: OWASP Nettacker is a testing framework that includes a range of features for identifying web cache poisoning vulnerabilities, including parameter manipulation and HTTP response splitting.

  3. Metasploit: Metasploit is a popular penetration testing framework that includes a range of modules for identifying and exploiting web cache poisoning vulnerabilities.

  4. Vega: Vega is a web application testing framework that includes a range of features for identifying web cache poisoning vulnerabilities, including the ability to intercept and modify HTTP requests and responses.

  5. Nikto: Nikto is a web server scanner that includes a range of features for identifying

Average CVSS score of Web Cache Poisoning Attacks

The average CVSS score for web cache poisoning attacks can vary widely depending on the specific vulnerability being exploited and the impact it has on the system. Some attacks may have a relatively low impact and receive a CVSS score in the range of 1-3, while others may have a much more significant impact and receive a score in the range of 7-10.

For example, a simple cache poisoning attack that allows an attacker to insert arbitrary content into a cache may have a CVSS score in the range of 2-4, depending on the impact of the attack. On the other hand, a more complex attack that allows an attacker to gain privileged access to a system or to exfiltrate sensitive data may have a CVSS score in the range of 7-10.

Overall, the average CVSS score for web cache poisoning attacks is likely to be moderate to high, as these vulnerabilities have the potential to cause significant harm to systems and data. As such, it is important for organizations to take steps to identify and mitigate these vulnerabilities in order to protect against potential attacks.

The Common Weakness Enumeration (CWE) Web Cache Poisoning Attacks

List of Common Weakness Enumeration (CWE) for Web Cache Poisoning Attacks:

  1. CWE-352: Cross-Site Request Forgery (CSRF) Description: An attacker can exploit a web cache poisoning vulnerability to perform CSRF attacks. This can allow them to execute unauthorized actions on behalf of a victim user.

  2. CWE-416: Use After Free Description: A use-after-free vulnerability can occur in a web cache if the cache retains a reference to an object that has been freed. An attacker can exploit this to execute arbitrary code or cause a denial of service.

  3. CWE-434: Unrestricted Upload of File with Dangerous Type Description: An attacker can exploit a web cache poisoning vulnerability to upload a file with a dangerous file type, such as a malicious JavaScript file, which can then be served to other users.

  4. CWE-613: Insufficient Session Expiration Description: A web cache can retain sensitive session data, such as session tokens, for an extended period of time. An attacker can exploit this to hijack a user’s session and gain unauthorized access to sensitive data.

  5. CWE-754: Improper Check for Unusual or Exceptional Conditions Description: A web cache may not properly check for unusual or exceptional conditions, such as a request with a large number of parameters. An attacker can exploit this to cause a denial of service or execute arbitrary code.

  6. CWE-798: Use of Hard-coded Credentials Description: Hard-coded credentials, such as default login credentials for a web cache, can be exploited by attackers to gain unauthorized access to the system.

  7. CWE-862: Missing Authorization Description: A web cache may not properly enforce authorization policies, allowing attackers to access unauthorized resources or perform unauthorized actions.

  8. CWE-863: Incorrect Authorization Description: A web cache may incorrectly enforce authorization policies, allowing attackers to access or modify resources that they should not have access to.

  9. CWE-908: Use of Uninitialized Resource Description: An uninitialized resource, such as a variable in a web cache, can be exploited by attackers to execute arbitrary code or cause a denial of service.

  10. CWE-918: Server-Side Request Forgery (SSRF) Description: An attacker can exploit a web cache poisoning vulnerability to perform SSRF attacks, which can allow them to access internal resources or perform other unauthorized actions.

  11. CWE-926: Improper Export of Android Application Components Description: A web cache used by an Android application may export sensitive data, such as authentication tokens or user data, to other applications on the same device.

  12. CWE-943: Improper Neutralization of Special Elements used in an SQL Command Description: An attacker can exploit a web cache poisoning vulnerability to inject SQL commands into a database query, allowing them to access or modify sensitive data.

  13. CWE-1004: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute Description: A web cache may retain sensitive cookies, such as session cookies, even if the session was initiated over HTTPS without the ‘Secure’ attribute. An attacker can exploit this to hijack a user’s session.

  14. CWE-1021: Improper Restriction of Rendered UI Layers or Frames Description: An attacker can exploit a web cache poisoning vulnerability to inject content into an iframe or other UI element, potentially leading to phishing attacks or other unauthorized actions.

  15. CWE-1034: XML External Entity (XXE) Injection Description: An attacker can exploit a web cache poisoning vulnerability to inject XML external entities, which can allow them to access sensitive data or execute arbitrary code.

  16. CWE-1135: Improper Access Control (Authorization) Description: A web cache may not properly enforce access control policies, allowing attackers to access or modify sensitive data without proper authorization.

  17. CWE-1210: Buffer Copy without Checking Size of Input Description: A web cache may not properly check the size of input data when copying it into a buffer. An attacker can exploit this to cause a buffer overflow and execute arbitrary code.

  18. CWE-1256: External Control of Critical State Data Description: An attacker can exploit a web cache poisoning vulnerability to manipulate critical state data, such as session cookies or authentication tokens, to gain unauthorized access to sensitive data.

  19. CWE-1299: Incomplete Blacklist Description: A web cache may use an incomplete blacklist to block certain types of requests, allowing attackers to exploit the cache to access or modify sensitive data.

  20. CWE-1300: Incorrect Handling of Exceptional Conditions Description: A web cache may not properly handle exceptional conditions, such as requests with invalid parameters or malformed data, allowing attackers to cause a denial of service or execute arbitrary code.

  21. CWE-1314: Uncontrolled Format String Description: A web cache may not properly sanitize user input when formatting output, allowing attackers to inject format string specifiers and execute arbitrary code.

  22. CWE-1349: Use of Hard-coded Cryptographic Key Description: A web cache may use hard-coded cryptographic keys, such as for encryption or authentication, which can be exploited by attackers to gain unauthorized access to sensitive data.

  23. CWE-1363: Improperly Configured Permissions Description: A web cache may be improperly configured, allowing attackers to access or modify sensitive data or execute arbitrary code.

  24. CWE-1379: Improper Handling of Unicode Encoding Description: A web cache may not properly handle Unicode encoding, allowing attackers to exploit the cache to execute arbitrary code or cause a denial of service.

  25. CWE-1382: Integer Underflow (Wrap or Wraparound) Description: A web cache may not properly handle integer underflow, allowing attackers to cause a denial of service or execute arbitrary code.

These are just a few examples of the many CWEs that can be related to web cache poisoning attacks.

Latests 10 CVEs related to Web Cache Poisoning Attacks

CVE-2021-41451 A misconfiguration in HTTP/1.0 and HTTP/1.1 of the web interface in TP-Link AX10v1 before V1_211117 allows a remote unauthenticated attacker to send a specially crafted HTTP request and receive a misconfigured HTTP/0.9 response, potentially leading into a cache poisoning attack.

CVE-2021-41267 Symfony/Http-Kernel is the HTTP kernel component for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Headers that are not part of the “trusted_headers” allowed list are ignored and protect users from “Cache poisoning” attacks. In Symfony 5.2, maintainers added support for the `X-Forwarded-Prefix` headers, but this header was accessible in SubRequest, even if it was not part of the “trusted_headers” allowed list. An attacker could leverage this opportunity to forge requests containing a `X-Forwarded-Prefix` header, leading to a web cache poisoning issue. Versions 5.3.12 and later have a patch to ensure that the `X-Forwarded-Prefix` header is not forwarded to subrequests when it is not trusted.

CVE-2021-32004 This issue affects: Secomea GateManager All versions prior to 9.6. Improper Check of host header in web server of Secomea GateManager allows attacker to cause browser cache poisoning.

CVE-2021-29479 Ratpack is a toolkit for creating web applications. In versions prior to 1.9.0, a user supplied `X-Forwarded-Host` header can be used to perform cache poisoning of a cache fronting a Ratpack server if the cache key does not include the `X-Forwarded-Host` header as a cache key. Users are only vulnerable if they do not configure a custom `PublicAddress` instance. For versions prior to 1.9.0, by default, Ratpack utilizes an inferring version of `PublicAddress` which is vulnerable. This can be used to perform redirect cache poisoning where an attacker can force a cached redirect to redirect to their site instead of the intended redirect location. The vulnerability was patched in Ratpack 1.9.0. As a workaround, ensure that `ServerConfigBuilder::publicAddress` correctly configures the server in production.

CVE-2021-23336 The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.

CVE-2020-4896 IBM Emptoris Sourcing 10.1.0, 10.1.1, and 10.1.3 is vulnerable to web cache poisoning, caused by improper input validation by modifying HTTP request headers. IBM X-Force ID: 190987.

CVE-2020-4828 IBM API Connect 10.0.0.0 through 10.0.1.0 and 2018.4.1.0 through 2018.4.1.13 is vulnerable to web cache poisoning, caused by improper input validation by modifying HTTP request headers. IBM X-Force ID: 189842.

CVE-2020-36283 HID OMNIKEY 5427 and OMNIKEY 5127 readers are vulnerable to CSRF when using the EEM driver (Ethernet Emulation Mode). By persuading an authenticated user to visit a malicious Web site, a remote attacker could send a malformed HTTP request to upload a configuration file to the device. An attacker could exploit this vulnerability to perform cross-site scripting attacks, Web cache poisoning, and other malicious activities.

CVE-2020-29022 Failure to Sanitize host header value on output in the GateManager Web server could allow an attacker to conduct web cache poisoning attacks. This issue affects Secomea GateManager all versions prior to 9.3

CVE-2020-28473 The package bottle from 0 and before 0.12.19 are vulnerable to Web Cache Poisoning by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.

The list of CVEs is constantly being updated and full an up-to-date list of all existed Common Vulnerabilities and Exposures (CVEs) for HTTP Request Smuggling vulnerabilities can be found at official CVE website https://cve.mitre.org/

List of popular exploits related to Web Cache Poisoning

Web cache poisoning attacks can be carried out using a variety of techniques and exploits. Here is a list of popular exploits related to web cache poisoning attacks:

  1. HTTP Response Splitting: This attack technique involves inserting a new line character followed by a malicious HTTP header into an HTTP response. The web cache may not properly handle the response, resulting in the malicious header being cached and served to subsequent users.

  2. Cache Deception Attack: This attack involves tricking a web cache into caching and serving a fake resource instead of the legitimate resource. This is often done by appending a parameter to the URL that is ignored by the web server but causes the web cache to treat the request as a new resource.

  3. Content Spoofing: This attack involves manipulating the content of a cached resource to display misleading or malicious information to users. This can be done by inserting malicious content into the cache, or by exploiting vulnerabilities in the content management system that generates the cache.

  4. Cross-Site Scripting (XSS): This attack involves injecting malicious code into a cached resource, which is then executed when the resource is served to subsequent users. This can allow attackers to steal sensitive information or execute arbitrary code on the user’s system.

  5. Request Smuggling: This attack involves manipulating the HTTP request headers to bypass security controls and carry out attacks on the web cache or the web server. This can allow attackers to poison the cache or gain access to sensitive information.

  6. Cache Poisoning via HTTP Request Smuggling: This attack technique involves using request smuggling to bypass security controls and poison the web cache by injecting a malicious request into the cache.

  7. Cache Poisoning via Cross-Site Scripting: This attack technique involves injecting a malicious script into a cached resource via a cross-site scripting vulnerability, which can then be served to subsequent users.

  8. Cache Poisoning via Server-Side Request Forgery (SSRF): This attack technique involves using a server-side request forgery vulnerability to poison the web cache by requesting a malicious resource that is then cached and served to subsequent users.

  9. Cache Poisoning via Parameter Pollution: This attack technique involves manipulating the parameters of a URL to trick the web cache into caching a malicious resource.

  10. Cache Poisoning via Content Injection: This attack technique involves injecting malicious content into a cached resource, which can then be served to subsequent users.

These are just a few examples of popular exploits related to web cache poisoning attacks.

Practice identifying and exploiting Web Cache Poisoning

If you are interested in learning about web cache poisoning attacks and how to defend against them, here are some recommendations:

  1. Read up on the basics: Start by learning the basics of web cache poisoning, including the different types of attacks, the vulnerabilities that can be exploited, and the potential impact on systems and data. You can find many online resources and articles on this topic, including academic papers and technical blogs.

  2. Practice on vulnerable applications: There are several intentionally vulnerable web applications that can be used for testing and practicing web cache poisoning attacks. These include DVWA, Mutillidae, and WebGoat. By using these tools, you can experiment with different techniques and get a better understanding of how web cache poisoning works in practice.

  3. Attend training or workshops: There are many cybersecurity training courses and workshops that cover web cache poisoning and other advanced attack techniques. Attending these can give you hands-on experience and provide you with expert guidance and advice.

  4. Join online communities: There are several online communities and forums dedicated to web application security and web cache poisoning. Joining these communities can provide you with access to experts and peers who can answer your questions and help you learn more about this topic.

  5. Use security tools: There are several security tools available that can help you identify and test for web cache poisoning vulnerabilities. These include Burp Suite, OWASP ZAP, and Nmap. By using these tools, you can test your own applications or other sites to identify potential vulnerabilities and learn how to defend against them.

To become proficient in web cache poisoning, it is important to practice and experiment with different techniques and tools. With dedication and persistence, you can develop the skills and knowledge needed to protect against this type of attack and enhance the security of web applications.

Books with review of Web Cache Poisoning

Here are some popular books on web cache poisoning that you might find helpful:

  1. “The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws” by Dafydd Stuttard and Marcus Pinto – This book provides a comprehensive guide to web application security and includes a detailed section on web cache poisoning. It is a must-read for anyone interested in learning about this topic.

  2. “Mastering Modern Web Penetration Testing” by Prakhar Prasad – This book covers a range of web application security topics, including web cache poisoning. It is an excellent resource for anyone looking to learn the latest techniques and best practices for web application security testing.

  3. “OWASP Testing Guide v4” by The Open Web Application Security Project – This guide provides a comprehensive overview of web application security testing and includes a section on testing for web cache poisoning vulnerabilities. It is a valuable resource for both beginners and experienced security professionals.

  4. “Hacking Exposed Web Applications, 3rd Edition” by Joel Scambray, Vincent Liu, and Caleb Sima – This book provides a detailed overview of web application security and includes a section on web cache poisoning. It is a valuable resource for anyone looking to learn about the latest threats and vulnerabilities facing web applications.

  5. “Black Hat Python: Python Programming for Hackers and Pentesters” by Justin Seitz – This book provides an in-depth guide to using Python for hacking and penetration testing, including techniques for exploiting web cache poisoning vulnerabilities. It is a valuable resource for anyone interested in using Python for offensive security purposes.

List of payloads for Web Cache Poisoning

Here are some common payloads that can be used for web cache poisoning attacks:

  1. Redirection Payloads: These payloads are used to redirect users to a malicious site or a phishing site. The payload can be injected into a web page, and when a user clicks on a link or submits a form, they are redirected to the malicious site.

  2. Malware Payloads: These payloads can be used to inject malware into a web page or a web application. The payload can be designed to exploit vulnerabilities in the target system, allowing an attacker to gain access and install malware on the system.

  3. XSS Payloads: Cross-Site Scripting (XSS) payloads can be used to steal sensitive information from users or execute malicious scripts on the victim’s browser. By injecting an XSS payload into a web page, an attacker can steal user cookies, login credentials, and other sensitive information.

  4. CSRF Payloads: Cross-Site Request Forgery (CSRF) payloads can be used to perform unauthorized actions on behalf of the victim. By injecting a CSRF payload into a web page, an attacker can trick the victim into performing an action, such as transferring money or deleting data.

  5. Cache Poisoning Payloads: These payloads are specifically designed to poison the web cache and cause it to serve malicious content to unsuspecting users. The payload can be injected into a web page or a request header and can be used to modify or delete cached content.

  6. Data Tampering Payloads: These payloads can be used to modify data stored in the web cache or the target web application. The payload can be designed to exploit vulnerabilities in the target system, allowing an attacker to modify or delete data on the system.

These are just some examples of common payloads that can be used for web cache poisoning attacks. The specific payload used will depend on the attacker’s goals and the vulnerabilities present in the target system.

Mitigation and how to be protected from Web Cache Poisoning

Here are some mitigation techniques and best practices to protect against web cache poisoning attacks:

  1. Disable or Limit Caching: One of the simplest ways to protect against web cache poisoning attacks is to disable or limit caching. By limiting the amount of data stored in the cache, the impact of a cache poisoning attack can be minimized.

  2. Use HTTPS: Using HTTPS can help to protect against man-in-the-middle attacks and prevent attackers from intercepting and modifying requests and responses. HTTPS also ensures that the data transmitted between the client and server is encrypted and secure.

  3. Use Strong Authentication: Strong authentication can help to prevent attackers from gaining access to sensitive data and taking control of the target system. By using strong passwords, two-factor authentication, and other security measures, you can reduce the risk of a successful attack.

  4. Implement Input Validation: Input validation is an important step in preventing web cache poisoning attacks. By validating input data, you can ensure that only safe and authorized requests are processed by the server.

  5. Keep Software Up-to-Date: Keeping software and systems up-to-date is critical for preventing web cache poisoning attacks. By installing security patches and updates, you can ensure that known vulnerabilities are addressed and mitigated.

  6. Perform Regular Security Audits: Regular security audits can help to identify and address vulnerabilities in the target system. By performing regular audits and penetration testing, you can identify potential weaknesses and take steps to address them before they can be exploited by attackers.

  7. Implement Security Headers: Implementing security headers such as Content-Security-Policy (CSP), X-Content-Type-Options, and X-XSS-Protection can help to prevent web cache poisoning attacks. These headers provide additional security measures and prevent attackers from injecting malicious content into web pages.

Overall, these are just some of the best practices and mitigation techniques that can help to protect against web cache poisoning attacks. By implementing these measures and staying vigilant, you can reduce the risk of a successful attack and protect your web applications and systems from potential threats.

Conclusion

Web Cache Poisoning is a serious and potentially devastating attack that can be used to compromise web applications and systems. It occurs when an attacker injects malicious content into the cache of a web server, causing it to serve the content to unsuspecting users. Web cache poisoning can be used to redirect users to malicious sites, steal sensitive information, inject malware, and perform unauthorized actions on behalf of the victim. To protect against web cache poisoning attacks, it is important to implement best practices such as limiting caching, using HTTPS, strong authentication, input validation, keeping software up-to-date, performing regular security audits, and implementing security headers.

Other Services

Ready to secure?

Let's get in touch