Skip to content

2. Delimiter Discrepancies

Was sind Delimiter discrepancies¶

Delimiters sind Zeichen, die in einer URL Elemente voneinander trennen z. B: /, ?, #, ; Delimiters discrepancies heißt: verschiedene Komponenten (Origin Server, Cache..) interpretieren diese Trennzeichen anders - dadurch kann derselbe URL-String von Server und Cache unterschiedlich geparsed werden. Das kann dann später Möglichkeiten für Web Cache Deception liefern

zB URL: /profile;asd.css -> FĂĽhrt zu unterschiedlichen Interpretationen

Java-Spring: ; = Matrix Parameter. Spring sieht die URL /profile als Anfrage und ignoriert den Rest Cache/Proxy: /profile;asd.css = Viele Caches sehen das ganze als Teil des Pfads und interpretiert das anders. AuĂźerdem bei .css denkt Cache es ist Cachebar obwohl es vielleicht doch ein Pfad fĂĽr dynamische Inhalte sein soll.

Häufige Delimiter / Normalisierungs-Unterschiede¶
  • ; (Matrix-Parameter)
  • / vs. // (mehrere Slashes)
  • . und Dateiendungen (.css, .jpg)
  • URL-Encodings (%2F, %2E)
  • Trailing slash (/foo vs /foo/)
  • Pfad-Normalisierung (/a/b/../c)
  • Query-Separator ? vs. Pfad-Parameter
Praktisches Testen in (Burp)¶
  1. Finde dynamischen Endpoint: /profile oder /my-account.

  2. Teste verschiedene Varianten in Repeater:

    • /profile;foo.css
    • /profile/foo.css
    • /profile%3Bfoo.css (encoded ;)
    • /profile%2Ffoo.css (encoded /)
    • /profile/../profile.css

  3. Schau, ob der Server trotzdem die dynamische Seite zurĂĽckgibt.

  4. Falls ja, prĂĽfe Cache-Verhalten (zweiter Request, X-Cache, Age, Antwortzeit).
  5. Wenn ohne Cookie dieselbe Seite zurückkommt → Cache-Vergiftung gelungen.

Merke: Manche Browser verabeiten schon Characters wie {, }, <, >, # wodurch dann der eigentliche Exploite Link nicht die korrekte Anfrage an Origin Server schickt -> Verpacke Link als encoded

Best-Practice Gegenmaßnahmen¶
  • Markiere dynamische Antworten: Cache-Control: no-store, private html Cache-Control: no-store, no-cache, private, max-age=0 Pragma: no-cache Vary: Cookie
  • Whitelist statischer Pfade (/static/*) statt Endungen pauschal cachen 
    # Block dynamische Endpunkte vom Caching
location /my-account {
    add_header Cache-Control "no-store, no-cache, private, max-age=0";
    add_header Pragma "no-cache";
    add_header Vary "Cookie";
    proxy_pass http://app;
}

# Nur statische Pfade cachen (whitelist)
location /static/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 30d;
    add_header Cache-Control "public, max-age=2592000";
    proxy_pass http://cdn_origin;
}
  • Pfadnormalisierung vereinheitlichen (Proxy + App gleich konfigurieren)
  • CDN/Proxy so konfigurieren, dass ungewöhnliche Delimiter (;, Encodings) richtig behandelt werden
  • Vary: Cookie oder ähnliche Header nutzen, wenn Responses pro-User unterschiedlich sind

🖥️🧪Lab-Part:¶

  1. Ziel-Endpunkt identifiziert: /my-account (enthält Benutzer-API-Key, erreichbar mit wiener:peter-Session).
  2. Delimiter/Path-Tests: verschiedene Varianten ausprobiert
    • /my-accountAAA → funktioniert nicht (anderer Pfad → kein Match).
    • /my-account;asd → Server ignoriert ;asd und liefert normale Account-Seite → Kandidat.
  3. Extension testen: an den Delimiter eine statische Endung gehängt, z. B.
    • /my-account;asd.css → Cache-Miss
    • /my-account;asd.ico → Server liefert weiterhin dynamische Account-HTML, Cache sieht aber .ico.
  4. Cache-Verifikation (Priming): /my-account;asd.ico mit gültiger Session angefragt → zweimal senden → Header zeigten Cache-Control: max-age=30, X-Cache: hit, Age: N → Cache hat gespeichert.

  5. Exploit bauen: Exploit-Server angelegt mit verstecktem Bild, das die URL lädt: <img style="display:none" src="https://<lab-domain>/my-account;asd.ico">

    → „Deliver exploit to victim“: Victim (carlos) lädt die Seite. 6. Finaler Abruf ohne Cookie: dieselbe URL /my-account;asd.ico ohne Cookie in Burp angefragt → Cache lieferte carlos’ Account-HTML (API-Key)

Was sind Delimiter decoding discrepancies¶

Manchmal werden Daten in der URL ĂĽbertragen die aber eigentlich Sonderzeichen sind. Damit diese Zeichen als Daten behandelt werden muss man diese manchmal encoden (percent-codiert) - Manche Parser decodieren gewisse Zeichen bevor diese weiterverabeitet werden. Wenn ein codiertes Trennzeichen decodiert wird, kann es als Trennzeichen dienen und LĂĽcken schaffen.

Origin-Server und Cache-Server decodieren oft unterschiedlich, sodass z. B: /profile%23wcd.css (%23 = #) - Der Origin-Server dekodiert %23 → #, nutzt # als Delimiter und interpretiert die Anfrage als /profile → gibt Profildaten zurück. - Der Cache dekodiert %23 nicht, sieht also /profile%23wcd.css. Weil das wie *.css aussieht, kann der Cache die Antwort als statische .css-Datei speichern.

Wichtige Encodings¶

%3B  ;   (Semikolon)
%23  #   (Hash)
%3F  ?   (Question mark)
%2F  /   (Slash)
%2E  .   (Dot)
%00  NUL (Null byte)
%0A  LF  (Line feed / newline)
%09  TAB (Tabulator)
%25  %   (Percent)

Zusätzliche Hinweise / Fallen¶

  • Intruder: wenn du viele Encodings testen willst, schalte URL-Encoding aus oder gib bereits encodete Payloads ein.
  • Double decoding: Manchmal musst du %253B testen (erst Cache decodiert zu %3B, dann Origin zu ;).
  • Nicht-druckbare Zeichen können besonders effektiv sein (%00, %0A, %09). Vorsicht beim EinfĂĽgen/Anzeigen in Tools.
  • TTL & Headers: prĂĽfe Cache-Control, Set-Cookie, Vary. no-store/private verhindert meist das Caching.
  • Exakt gleiche URL verwenden fĂĽr Priming und finalen Abruf — keine Query-Parameter oder Cache-Buster