Skip to content

3. Normalization Discrepancies

Was sind Normalization discrepancies?¶

Normalisierung = verschiedene Formen einer URL in eine kanonische Form überführen (z. B. %2F → /, a/../b → b).
Normalization discrepancy liegt vor, wenn Cache und Origin-Server die URL unterschiedlich normalisieren (decodieren oder Dot-Segmente auflösen). Dadurch kann dieselbe Request-URL vom Cache anders interpretiert werden als vom Origin - Grundlage für Web Cache Deception.

Was ist das Problem dahinter?¶

Wenn der Cache eine URL als /static/... sieht (also eine statische Resource) und cacht, aber der Origin dieselbe URL nach Normalisierung als /profile interpretiert und dynamische Inhalte zurĂĽckgibt, landet dynamischer Inhalt unter einem statischen Cache-Key - Leak!

Beispielkonzept: - Du rufst etwas wie: /static/../../my-account/foo.ico

- **Cache** sieht den Pfad, sieht `/static/` vorne und denkt: „das ist statisch → cachebar“.
- **Origin** normalisiert den Pfad (`/static/../../my-account/foo.ico` → `/my-account/foo.ico`) und liefert die dynamische Seite.
- Ergebnis: dynamische Seite landet als `/static/../../my-account/foo.ico` im Cache und kann später von jedem abgeholt werden.

🖥️🧪Lab-Part:¶

  • Origin-Normalisierung getestet:

    • In Burp Repeater GET /static/..%2Fmy-account gesendet.
      • .. = Ein verzeichnis hoch
      • %2F = / decoded
    • Ergebnis: Origin decodiert/normalisiert und lieferte die normale /my-account-Seite (Account HTML). → Origin normalisiert.

  • Cache-Mapping geprĂĽft:

    • In Burp → HTTP history geschaut und festgestellt: alle Requests unter /resources/... liefern X-Cache: hit / Age → der Cache speichert Inhalte mit dem /resources-Prefix. → /resources ist in Cache-Regel enthalten.

  • Exploit-URL gebaut:

    • Payload: 
      <img style="display:none" src="https://0ae50035035bf632802f1c9d00340013.web-security-academy.net/resources/..%2Fmy-account">

  • Diese URL sieht fĂĽr den Cache wie eine statische /resources/...-Ressource aus, der Origin normalisiert sie aber zu /my-account.

  • Exploit ausgeliefert & gewartet:

    • Exploit an Ziel (carlos) geliefert; im Exploit-Server-Log bestätigt, dass das Opfer die Seite geladen hat.

  • Finaler Abruf (ohne Cookie):

    • Dieselbe URL (byte-gleich) ohne Cookie: im Repeater angefragt.
    • Ergebnis: Cache lieferte die zuvor von carlos erzeugte Account-Seite → API-Key erhalten.

Exploiting Cache Server normalization¶

Wenn Cache und Origin Server URL unterschiedlich decoden kann man sich das manchmal zu nutze machen, sodass man beim Cache eine encoded Anfrage schickt die dann durch einen eingefĂĽgten Delimeter korrekt beim Origin-Server ankommen obwohl er die Anfrage eigentlich ganz falsch interpretieren wĂĽrde.

Man nutzt Unterschiede aus, wie Cache-Server und Origin-Server URLs interpretieren. - Der Cache normalisiert Pfade (z. B. /profile%2f%2e%2e%2fstatic → /static). - Der Origin-Server tut das nicht und sieht die URL anders (z. B. /profile%2f%2e%2e%2fstatic → Fehler oder /profile).

Durch einen Delimeter-Trick (z. B. ;) kann man erreichen, dass: - Cache: /static → speichert die Antwort. - Origin-Server: /profile → gibt dynamische Daten zurück.

Lab-Part:¶

  1. Origin-Delimiter getestet (Intruder):**

    • In Burp Repeater /my-accountabc → 404.
    • Anfrage an Intruder geschickt mit Payload-Position /my-account§§abc.
    • Liste an Delimitern (?, ;, #, %23, %3f …) durchlaufen.
    • Ergebnis: ?, %23, %3f, # liefern 200 OK + API-Key → Origin interpretiert diese Zeichen als Pfad-Delimiter.

  2. Cache-Verhalten geprĂĽft:

    • In Burp Proxy gesehen: Inhalte unter /resources/... werden gecached (X-Cache: hit/miss).
    • Cache normalisiert ..%2f Traversals → /../.
    • Fazit: Cache-Regel aktiv fĂĽr /resources/*.

  3. Exploit-URL gebaut:

    • Payload: /my-account%23%2f%2e%2e%2fresources
    • Origin: durch %23 wird nur /my-account ausgeliefert (API-Key).
    • Cache: interpretiert den Rest als /resources/... → speichert die Antwort.

  4. Exploit ausgeliefert & gewartet:

    • Im Exploit-Server Script eingebaut: 
      <img style="display:none" src="https://0ae50035035bf632802f1c9d00340013.web-security-academy.net/my-account%23%2f%2e%2e%2fresources?">

  5. Finaler Abruf (ohne Cookie):

    • Dieselbe URL ohne Cookie: erneut abgerufen.
    • Ergebnis: Cache lieferte Carlos’ Account-Seite inkl. API-Key.