HTTPS Cache Poisoning: CVSS Impact

TL;DR

A misconfigured HTTPS server can cache responses that include sensitive information or incorrect redirects. This allows attackers to potentially serve malicious content to users, even with a valid SSL certificate. The severity depends on what’s cached and how it’s used.

Understanding the Problem

Normally, HTTPS caches are designed to only cache safe resources. However, errors in server configuration or application logic can lead to caching of responses that shouldn’t be cached – like pages with user-specific data, authentication tokens, or redirect URLs. When this happens, an attacker might be able to ‘poison’ the cache by injecting a malicious response.

Steps to Identify and Mitigate

1. Check Cache Control Headers: The most important step is verifying your server’s Cache-Control headers. These tell browsers (and proxies) how long to store responses.
   • No-cache, No-store, Private: These are generally the safest options for sensitive content. no-cache means revalidate with the server before using a cached copy. no-store prevents caching altogether. private indicates that only the user’s browser should cache the response.
   • Public, Max-Age: Be very careful with these! public allows caching by any intermediary proxy. max-age specifies how long (in seconds) a resource can be cached.

   You can use browser developer tools (Network tab) or command-line tools like curl to inspect headers:

   curl -I https://yourdomain.com/sensitivepage

2. Inspect Redirects: If your application uses redirects, ensure they are not being cached.
   • Cached redirects can point users to malicious sites even if the original site is secure.
   • Use Cache-Control: no-cache on redirect responses.
3. Review Application Logic: Look for places in your code where you might be inadvertently caching sensitive data.
   • Dynamic content generation that isn’t properly marked as uncacheable is a common issue.
   • Check any custom caching mechanisms you’ve implemented.
4. Test with Cache Poisoning Tools: Several tools can help simulate cache poisoning attacks.
   • Burp Suite: A popular web security testing tool that includes features for manipulating HTTP requests and caching behaviour.
   • ZAP (OWASP Zed Attack Proxy): Another free and open-source web application scanner with similar capabilities.
5. Server Configuration: Check your web server’s configuration.
   • Nginx: Ensure the proxy_cache_bypass directive is correctly configured to prevent caching of sensitive URLs or responses based on headers (e.g., cookies).
   • Apache: Review your mod_cache settings and ensure appropriate cache control rules are in place.
6. HTTP Strict Transport Security (HSTS): While HSTS doesn’t directly prevent cache poisoning, it forces browsers to use HTTPS, reducing the risk of man-in-the-middle attacks that could exploit a poisoned cache.

   # Example Nginx HSTS configuration
   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

CVSS Impact Assessment

The CVSS score for a cache poisoning vulnerability depends on several factors:

• Attack Vector (AV): Typically Network (N) as the attack can be launched remotely.
• Attack Complexity (AC): Low (L) if the misconfiguration is easily exploitable.
• Privileges Required (PR): None (N) – no authentication required.
• User Interaction (UI): None (N) – typically, users are passively affected.
• Scope (S): Changed (C) if the attacker can affect other users of the system.
• Confidentiality Impact (C): High (H) if sensitive data is cached and exposed.
• Integrity Impact (I): High (H) if an attacker can inject malicious content.
• Availability Impact (A): May vary, potentially Low (L) to High (H) depending on the impact of injected content.

Based on these factors, a typical HTTPS cache poisoning vulnerability could score between 7.5 and 9.8 on the CVSS scale.