From f3a9af177a53a80225c9de70ca9accb2c0d290fe Mon Sep 17 00:00:00 2001
From: RRudder <96507400+RRudder@users.noreply.github.com>
Date: Fri, 7 Mar 2025 10:14:07 +1000
Subject: [PATCH] Adding Cache Deception category

This is to match the VRT minor update 1.15.1 (https://github.com/bugcrowd/vulnerability-rating-taxonomy/pull/453)
---
 .../cache_deception/recommendations.md        | 16 ++++++++++++
 .../cache_deception/template.md               | 25 +++++++++++++++++++
 2 files changed, 41 insertions(+)
 create mode 100644 submissions/description/server_security_misconfiguration/cache_deception/recommendations.md
 create mode 100644 submissions/description/server_security_misconfiguration/cache_deception/template.md

diff --git a/submissions/description/server_security_misconfiguration/cache_deception/recommendations.md b/submissions/description/server_security_misconfiguration/cache_deception/recommendations.md
new file mode 100644
index 00000000..f79500fe
--- /dev/null
+++ b/submissions/description/server_security_misconfiguration/cache_deception/recommendations.md
@@ -0,0 +1,16 @@
+# Recommendation(s)
+
+The most effective way to prevent cache deception is to carefully control which responses are cached and to avoid caching responses that contain user-specific or sensitive data.
+
+Ensure that authentication-protected pages and any responses containing sensitive information explicitly disable caching via headers such as `Cache-Control: no-store, no-cache, must-revalidate` and `Pragma: no-cache`.
+
+Be particularly cautious with URL structures. Cache deception attacks often rely on tricking the cache into treating dynamic responses as static. A simple mitigation is to ensure that URLs ending in extensions like `.css`, `.js`, `.png`, etc., only serve static content and do not process dynamic requests.
+
+For additional protection, configure your cache layer to only cache responses from a predefined allowlist of safe URL patterns. This prevents attackers from injecting deceptive paths that lead to cached sensitive data.
+
+Auditing your cache behavior using tools like Param Miner or manual testing can help identify and eliminate unintended caching of sensitive responses. Additionally, security headers such as `X-Content-Type-Options: nosniff` can help prevent certain forms of cache-related attacks.
+
+Finally, if your application uses a CDN or a reverse proxy (e.g., Cloudflare, Akamai, Varnish), ensure that caching rules are correctly configured to prevent caching of personalized or user-specific content.
+
+For more information, refer to the following resource:
+<https://portswigger.net/web-security/web-cache-deception>
diff --git a/submissions/description/server_security_misconfiguration/cache_deception/template.md b/submissions/description/server_security_misconfiguration/cache_deception/template.md
new file mode 100644
index 00000000..f9672466
--- /dev/null
+++ b/submissions/description/server_security_misconfiguration/cache_deception/template.md
@@ -0,0 +1,25 @@
+Cache deception allows an attacker to serve fake static files, forcing the web server to mistakenly cache and serve dynamic content as though it were static. If subsequent users make requests to the same URL, they are served the cached page. This can lead to sensitive data exposure for multiple users across different sessions.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company through the impact to customers’ trust.
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to navigate to the following url: {{URL}}
+1. Intercept the request in the HTTP interception Proxy and change HTTP header: {{value}} to {{value}}
+1. Forward the following request to the endpoint:
+
+```HTTP
+{{request}}
+```
+
+1. Notice that the following page is cached: {{screenshot}}
+1. Perform {{action}} to demonstrate cache deception
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) this vulnerability:
+
+{{screenshot}}