Κεφάλαιο 11 ΑΣΦΑΛΕΙΑ ΕΦΑΡΜΟΓΩΝ ΙΣΤΟΥ Σύνοψη Σε αυτό το κεφάλαιο αναπτύσσεται το θέµα της ασφάλειας στις διαδικτυακές εφαρµογές ιστού. Αναλύονται πρακτικά ζητήµατα ασφαλείας και δίνονται σχετικά παραδείγµατα. Η παρουσίαση ακολουθεί τη µεθοδολογία του «Top Ten Project» του Open Web Application Security Project (OWASP), το οποίο προδιαγράφει τις βασικές περιοχές ευπάθειας των διαδικτυακών εφαρµογών και τους τρόπους ανίχνευσης και αντιµετώπισής τους. Παρουσιάζεται το µοντέλο Role-Based Access Control (RBAC), δηλαδή ο µηχανισµός που αυθεντικοποιεί και εξουσιοδοτεί τα δικαιώµατα πρόσβασης των χρηστών σε ένα Πληροφοριακό Σύστηµα (ΠΣ). Επίσης, γίνεται αναφορά στην κρυπτογραφία και στις υποδοµές δηµόσιου κλειδιού (Public Key Infrastructure/PKI), καθώς και στα πρότυπα της Κοινοπραξίας του Παγκόσµιου Ιστού (World Wide Web Consortium/W3C), για την ασφάλεια των Υπηρεσιών Ιστού (Web Services/WS). Τέλος, παρουσιάζονται τα χαρακτηριστικά ασφάλειας της γλώσσας προγραµµατισµού Java. Προαπαιτούµενη γνώση 1) Κεφάλαια 5, 6, 7, 8, 9 και 10 του παρόντος. 2) Γ. Βαλάντης (2008), Ασφάλεια υπολογιστών και διαχείριση πληροφορίας, Π. Γκόνης (Κωδικός Βιβλίου στον Εύδοξο: 6390). 3) Γ. Πάγκαλος και Ι. Μαυρίδης (2002), Ασφάλεια πληροφοριακών συστηµάτων, Ε. και Δ. Ανίκουλα Ι. Αλέξικος (Κωδικός Βιβλίου στον Εύδοξο: 5425). 11.1. Γενικές έννοιες ασφάλειας σε επίπεδο εφαρµογών Ασφάλεια σε ένα ΠΣ ορίζεται η κατάσταση στην οποία δεν υπάρχει λειτουργικός ή επιχειρησιακός κίνδυνος, καθώς και η προστασία από έκθεση σε ατυχήµατα ή επιθέσεις. Στόχος της ασφάλειας των ΠΣ είναι η βελτιστοποίηση της απόδοσης µιας επιχείρησης ή ενός οργανισµού, λαµβάνοντας υπόψη τους κινδύνους (risks) στους οποίους αυτά εκτίθενται. Ο κίνδυνος αφορά την πιθανότητα ζηµιάς, καταστροφής ή απώλειας.[1] Ευπάθειες (vulnerabilities) είναι οι αδυναµίες ενός συστήµατος, τις οποίες µπορεί να εκµεταλλευτούν (exploit) κακόβουλοι χρήστες, προκειµένου να πραγµατοποιήσουν µια επίθεση (attack) εναντίον του. Άρα, υπάρχει διάκριση µεταξύ των όρων ευπάθειας και των όρων επίθεσης, δεδοµένου ότι ευπάθεια είναι η αδυναµία ενός συστήµατος, ενώ επίθεση είναι το σύνολο των ενεργειών ενός επιτιθέµενου, ο οποίος εκµεταλλεύεται µια ευπάθεια του συστήµατος-στόχου, προκειµένου να του προκαλέσει ζηµιά, παραβιάζοντας τους κανόνες λειτουργίας του ή/και κάποια πολιτική ασφαλείας. Μια επίθεση δεν είναι υποχρεωτικό ότι θα οδηγήσει πάντα σε επιτυχές αποτέλεσµα για τον επιτιθέµενο, δεδοµένου ότι αυτός µπορεί να µην καταφέρει να προσπελάσει τα «τείχη ασφαλείας» του συστήµατος ή µπορεί ακόµα η εκδηλωµένη επίθεση να γίνει αντιληπτή και να αντιµετωπιστεί επιτυχώς. Από την άλλη πλευρά, µια ευπάθεια µπορεί να υφίσταται για καιρό σε ένα σύστηµα και να αγνοείται από τους ιδιοκτήτες του συστήµατος ή/και από τους επιτιθέµενους. Όταν όµως γίνει αντιληπτή από έναν επιτιθέµενο, µπορεί να οδηγήσει σε καταστροφικά αποτελέσµατα (π.χ. όταν πρόκειται για οικονοµικούς φορείς, όπως είναι οι τράπεζες). Στην περίπτωση αυτή, θα πρέπει οι επιχειρήσεις και οι οργανισµοί να έχουν µηχανισµούς αντίδρασης σε περιστατικά ασφάλειας, οι οποίοι να εφαρµόζονται σύµφωνα µε τις οδηγίες και τις συναφείς διαδικασίες. Επίσης, πρέπει να γίνεται ανάλυση των ευπαθειών ενός συστήµατος µε εξελιγµένα εργαλεία. Η διαδικασία κατά την οποία ο στόχος και, γενικά, ένα σύστηµα αναλύονται για ευπάθειες ονοµάζεται αποτίµηση ευπαθειών (vulnerability assessment). Οι επιχειρήσεις και οι οργανισµοί καλούνται να κάνουν συνεχή εκτίµηση των κινδύνων (risk assessment) στους οποίους εκτίθενται, λόγω των ευπαθειών που παρουσιάζουν τα συστήµατά τους.
Δεδοµένου ότι τα ΠΣ έχουν εισχωρήσει σε κάθε λειτουργία των επιχειρήσεων και των οργανισµών, η ασφάλειά τους είναι ζωτικής σηµασίας και διέπεται από τις ακόλουθες τρεις βασικές αρχές:[2] Εµπιστευτικότητα (confidentiality): Εξασφαλίζει την πρόσβαση στην πληροφορία µόνο από εξουσιοδοτηµένα άτοµα. Ακεραιότητα (integrity): Εξασφαλίζει ότι η πληροφορία παραµένει αναλλοίωτη από µη επιθυµητές αλλαγές. Διαθεσιµότητα (availability): Εξασφαλίζει ότι η πληροφορία θα είναι διαθέσιµη για χρήση όποτε αυτό είναι απαραίτητο. Εικόνα 11.1 Η δοµή του project. Σε µια εφαρµογή ιστού, µπορεί να παρατηρηθούν πολλά σηµεία ευπάθειας, όπως η επίθεση σε µια εφαρµογή εξαιτίας κάποιας ευπάθειας στον εξυπηρετητή (server), στη βάση δεδοµένων, στο φυλλοµετρητή (browser), στη γλώσσα ανάπτυξης ή, ακόµα, και στην ίδια την εφαρµογή. Σχετικά µε το τελευταίο, υπάρχουν ευπάθειες που εισάγονται εξαιτίας της κακής σχεδίασης και υλοποίησης της εφαρµογής. Εν γένει, η γνώση των κινδύνων και των ευπαθειών είναι σηµαντική, προκειµένου να επιτευχθεί η ελαχιστοποίησή τους. Ως εκ τούτου, ο προγραµµατιστής και ο διαχειριστής της εφαρµογής/ιστοτόπου πρέπει να λαµβάνουν όλα εκείνα τα µέτρα που απαιτούνται γι αυτόν το λόγο. Στη συνέχεια, προσεγγίζουµε τις ευπάθειες, αλλά και τις απαντήσεις που µπορεί να δοθούν µε βάση τη λίστα «Ten Top Project» του οργανισµού OWASP.[3] 11.2. Απειλές ασφαλείας σύµφωνα µε τον OWASP: Το Ten Top Project Καταρχάς, θα εστιάσουµε στο ποιοι είναι οι κίνδυνοι σε ένα ΠΣ και ποιες οι σηµαντικότερες ευπάθειές του, σύµφωνα µε την κατηγοριοποίηση που έχει γίνει από τον οργανισµό OWASP, έναν παγκόσµιο, µη κερδοσκοπικό οργανισµό, στόχος του οποίου είναι η δηµιουργία λειτουργικών και ασφαλών εφαρµογών λογισµικού. Ο OWASP υποστηρίζεται από µια µεγάλη κοινότητα χρηστών και διαθέτει υλικό που είναι ελεύθερα προσβάσιµο στο κοινό.[4] Στη συνέχεια, θα παρουσιάσουµε τις σηµαντικότερες ευπάθειες, όπως αυτές αναφέρονται στη λίστα «Top Ten Project» του OWASP.
11.2.1 Έγχυση (injection) Στις επιθέσεις έγχυσης υπάγονται όλες οι επιθέσεις που σχετίζονται µε την εισαγωγή κακόβουλου κώδικα σε ένα σύστηµα διαµέσου του διερµηνέα (interpreter) µιας εφαρµογής. Ο επιτιθέµενος χρησιµοποιεί κακόβουλο κώδικα, που εκµεταλλεύεται τον τρόπο σύνταξης ενός διερµηνέα µιας γλώσσας λογισµικού, µε σκοπό να αποκτήσει πρόσβαση σε δεδοµένα στα οποία δεν έχει την απαραίτητη εξουσιοδότηση. Μια επίθεση τύπου έγχυσης µπορεί να πραγµατοποιηθεί µε ερωτήµατα σε γλώσσες, όπως είναι η SQL ή η LDAP,[5] µε εντολές του λειτουργικού συστήµατος ή/και µε άλλους τρόπους. Οι επιπτώσεις της επίθεσης αυτής είναι συνήθως σοβαρές, γιατί µπορεί να προκληθούν απώλεια δεδοµένων (data loss), άρνηση πρόσβασης στην υπηρεσία (denial of access), ενώ, στη χειρότερη περίπτωση, µπορεί ο επιτιθέµενος να πάρει τον έλεγχο ακόµα και ολόκληρου του συστήµατος. Κάθε εφαρµογή ιστού που επιτρέπει την εκτέλεση εντολών για την κλήση χρήσης εξωτερικών πόρων, όπως ερωτηµάτων SQL ή εντολών κελύφους (shell commands), είναι γενικά ευάλωτη σε επιθέσεις τύπου έγχυσης. Με λεπτοµερή εξέταση του κώδικα λογισµικού της εφαρµογής, εύκολα µπορεί να διαπιστωθεί εάν είναι τρωτή σε επιθέσεις έγχυσης, όχι όµως και σε επιθέσεις µέσω δοκιµών (testing). Για να ανακαλύψουµε αν µια εφαρµογή είναι ευάλωτη σε επιθέσεις έγχυσης, ψάχνουµε λεπτοµερώς τα σηµεία του κώδικα στα οποία καλούνται εξωτερικές πηγές ή συστήµατα. Στην Εικόνα 11.2 δίνεται ένα παράδειγµα επίθεσης έγχυσης, και συγκεκριµένα η επίθεση έγχυσης SQL. Εικόνα 11.2 Η επίθεση έγχυσης SQL. Στο συγκεκριµένο παράδειγµα επίθεσης έγχυσης SQL, ο επιτιθέµενος στέλνει (π.χ. σε µια φόρµα εισαγωγής δεδοµένων µιας ιστοσελίδας) την εντολή σε γλώσσα SQL, SELECT * FROM Users Where UserId = 1 or 1 = 1. Σκοπός της εντολής αυτής είναι να επιλέξει τους χρήστες από τον πίνακα Users, όπου έχουν το πεδίο UserId ίσο µε το 1. Αν δεν υπάρχει προστασία από κακόβουλη εισαγωγή δεδοµένων, µε το 1 = 1 επιστρέφονται όλες οι γραµµές του πίνακα Users, εφόσον η συνθήκη 1 = 1 είναι αληθής σε κάθε περίπτωση. Έτσι, ο επιτιθέµενος µπορεί να αποκτήσει πρόσβαση στη βάση δεδοµένων SQL του εξυπηρετητή σε αυτήν την περίπτωση. 11.2.1.1. Μέθοδοι προστασίας από επιθέσεις έγχυσης Για την αποφυγή επιθέσεων έγχυσης, είναι απαραίτητος ο διαχωρισµός των αµφιβόλου προέλευσης δεδοµένων εισόδου χρήστη από ερωτήµατα και εντολές. Ένας πιθανός τρόπος προστασίας είναι η αποφυγή χρήσης διερµηνέα. Η χρήση οποιουδήποτε διερµηνέα που ερµηνεύει κώδικα ο οποίος δηµιουργείται δυναµικά είναι επικίνδυνη, γιατί ο δυναµικός κώδικας µπορεί να µην έχει δηµιουργηθεί µε ασφαλή τρόπο. Αυτό όµως δεν είναι πάντα δυνατόν, αφού δηµιουργείται άλλο πρόβληµα, το οποίο αφορά τον τρόπο επικοινωνίας της εφαρµογής µε εξωτερικές πηγές. Γι αυτόν το λόγο, προτείνονται και άλλοι τρόποι, όπως η
χρήση ασφαλών διεπαφών προγραµµατισµού εφαρµογών (Application Programming Interface/API), µέσω των οποίων εκτελούνται οι ίδιες λειτουργίες µε αυτές των διερµηνέων. Στην περίπτωση µη διαθέσιµων API, συνίσταται η αποφυγή των ειδικών χαρακτήρων (special characters) από το διερµηνέα, µε τη χρήση σύνταξης διαφυγής (escape syntax). Στην περίπτωση της ασφαλούς προσπέλασης µιας βάσης δεδοµένων, προτείνεται η χρήση κάποιας βιβλιοθήκης Object-Relational Mapping (ORM), µε την οποία η πρόσβαση στη βάση δεδοµένων δεν γίνεται µέσω ερωτηµάτων SQL, αλλά µέσω δηµιουργίας και επεξεργασίας αντικειµένων. Αυτή η προσέγγιση αποφεύγει τις επιθέσεις έγχυσης SQL. Υπάρχουν και άλλοι τρόποι προστασίας από επιθέσεις έγχυσης. Οι τρόποι αυτοί περιλαµβάνουν, µεταξύ άλλων, την επαλήθευση εισόδου, την ισχυρή παραµετροποίηση των ερωτηµάτων, την επιβολή ελάχιστων προνοµίων κατά τη σύνδεση µε τη βάση δεδοµένων, τη διαχείριση των µηνυµάτων λάθους, ώστε να µην αποκαλύπτουν λεπτοµέρειες του συστήµατος, την προσεκτική χρήση των αποθηκευµένων διαδικασιών (store procedures) και την αποφυγή δυναµικών διεπαφών ερωτηµάτων, καθώς και απλών συναρτήσεων χαρακτήρων διαφυγής (escaping). Επίσης, προτείνεται η χρήση λευκών λιστών (white list), η οποία δεν αποτελεί, ωστόσο, το βέλτιστο µέτρο διαφυγής, διότι πολλές εφαρµογές απαιτούν ως είσοδο ειδικούς χαρακτήρες. Επιπρόσθετα, προτείνεται σε κάθε σηµείο εισόδου ή τροποποίησης δεδοµένων της εφαρµογής να γίνεται έλεγχος της ορθότητας των δεδοµένων αυτών, δηλαδή της αναµενόµενης µορφής τους. Αυτό περιλαµβάνει, προφανώς, και τον έλεγχο των κρυµµένων (hidden) πεδίων φόρµας, εφόσον βέβαια αυτά υπάρχουν.[4] 11.2.2 Ασθενής µηχανισµός αυθεντικοποίησης και διαχείρισης συνόδου Με τον όρο «αυθεντικοποίηση» (authentication) δηλώνεται η διαδικασία επιβεβαίωσης της ταυτότητας ενός χρήστη, µιας διεργασίας ή µιας συσκευής, µε σκοπό την εξασφάλιση πρόσβασης στους πόρους ενός ΠΣ. Για την υλοποίηση της αυθεντικοποίησης, χρησιµοποιούνται διάφορες τεχνικές, όπως η χρήση συνθηµατικών (password) και η πρόσβαση και η αυθεντικοποίηση βασισµένη σε κουπόνι (token-based) ή διπλό παράγοντα (two factor). Με τον όρο «διαχείριση συνεδρίας» (session management) δηλώνεται η διαδικασία µε την οποία διατηρούνται οι πληροφορίες κατάστασης του χρήστη για συγκεκριµένο χρονικό διάστηµα στη συνεδρία του φυλλοµετρητή µε τον εξυπηρετητή.[6] Σηµειώνεται ότι, σε αυτήν την περίπτωση, συγκαταλέγονται και όλα τα θέµατα που αφορούν τα cookies. Στην περίπτωση ενός ασθενούς µηχανισµού αυθεντικοποίησης και διαχείρισης συνόδου, ο επιτιθέµενος εκµεταλλεύεται αδύναµα σηµεία ή διαρροές στις διαδικασίες διαχείρισης συνεδρίας και αυθεντικοποίησης, για να προσποιηθεί συγκεκριµένο χρήστη και να αποκτήσει πρόσβαση στο σύστηµα-στόχο. Στην Εικόνα 11.3 παρουσιάζεται η υποκλοπή (sniffing) από έναν επιτιθέµενο του χαρακτηριστικού αναγνωριστικού (IDentifier) της συνεδρίας του πελάτη µε τον εξυπηρετητή, το οποίο χρησιµοποιεί αργότερα για να προσπελάσει τον εξυπηρετητή προς ίδιον όφελος.
Εικόνα 11.3 Υποκλοπή συνεδρίας από επιτιθέµενο. Η αδυναµία αυτή οφείλεται κυρίως στην κατασκευή µη ισχυρών µηχανισµών αυθεντικοποίησης και διαχείρισης συνεδριών, µε συνέπεια να υπάρχουν αδύναµα σηµεία σε λειτουργίες, όπως η αποσύνδεση (logout), η διαχείριση συνθηµατικού και η ενηµέρωση λογαριασµού. Αυτά τα αδύναµα σηµεία µπορεί να προκαλέσουν την επίθεση σε έναν ή ακόµα και σε όλους τους λογαριασµούς των χρηστών. Έτσι, ο επιτιθέµενος µπορεί να εκτελέσει τις ίδιες ενέργειες µε το χρήστη στου οποίου το λογαριασµό έχει πρόσβαση. Συνήθως, στόχος είναι οι λογαριασµοί χρηστών µε αυξηµένα δικαιώµατα, όπως οι λογαριασµοί των διαχειριστών (administrators). Ευάλωτοι σε αυτόν τον τύπο επίθεσης είναι όλοι οι εξυπηρετητές ιστού (web servers) και όλες οι εφαρµογές ιστού (web applications). Η επιτυχία της επίθεσης αυτής οφείλεται κυρίως: 1. στην αποστολή κωδικών πρόσβασης, αναγνωριστικών συνεδριών (session ID) και άλλων στοιχείων, µέσω µη κρυπτογραφηµένων καναλιών (nonencrypted channels), 2. στην ελλιπή προστασία των διαπιστευτηρίων (credentials) των χρηστών, τα οποία δεν είναι αποθηκευµένα σε κρυπτογραφηµένη (encrypted) ή σε κατακερµατισµένη (hashed) µορφή, 3. στην πιθανότητα ο επιτιθέµενος να µαντέψει τα διαπιστευτήρια ενός χρήστη ή να τα αντικαταστήσει µε δικά του, εξαιτίας αδύναµων λειτουργιών διαχείρισης λογαριασµού, 4. στο γεγονός ότι τα αναγνωριστικά των συνεδριών είναι ορατά στον υπερσύνδεσµο (Uniform Resource Locator/URL), 5. στο γεγονός ότι τα αναγνωριστικά συνεδριών, τα κουπόνια αυθεντικοποίησης (authentication tokens) ή οι συνεδρίες χρηστών δεν έχουν χρονικό όριο λήξης, οπότε κάποια στιγµή µπορεί να υποκλαπούν, εφόσον παραµένουν ενεργά. Τα εργαλεία εντοπισµού ευπαθειών (vulnerability scanning tools), όπως και τα εργαλεία στατικής ανάλυσης (static analysis tools) δυσκολεύονται αρκετά να εντοπίσουν την ευπάθεια αυτή, ενώ η επανεξέταση του κώδικα και ο έλεγχος, ειδικά όταν χρησιµοποιούνται σε συνδυασµό µε τα παραπάνω εργαλεία, αποτελούν ιδιαίτερα αποτελεσµατικές προσεγγίσεις, καθώς µπορούν να διαπιστώσουν ότι όλα έχουν υλοποιηθεί και λειτουργούν µε ασφαλή τρόπο. Παράδειγµα τέτοιας επίθεσης µπορεί να έχουµε σε µια πώληση προϊόντος από ένα ηλεκτρονικό κατάστηµα. Ένας αγοραστής µπορεί να θέλει να δείξει σε ένα φίλο του το προϊόν που αγόρασε. Έστω ότι δίνει τον παρακάτω (ενδεικτικό) υπερσύνδεσµο: http://test.com/sales/saleitem?sessionid=123456&item=tv. Με αυτόν τον τρόπο, το αναγνωριστικό συνεδρίας (sessionid=123456) είναι φανερό στον παραπάνω σύνδεσµο. Έτσι,
ένας κακόβουλος χρήστης µπορεί να χρησιµοποιήσει τη συνεδρία και να αποκτήσει πρόσβαση σε ευαίσθητες πληροφορίες, όπως στον αριθµό πιστωτικής κάρτας του χρήστη. Αυτό συµβαίνει διότι ο µηχανισµός διαχείρισης συνεδρίας είναι ασθενής και φαίνεται στον υπερσύνδεσµο. 11.2.2.1 Αντιµετώπιση για τους ασθενείς µηχανισµούς αυθεντικοποίησης και διαχείρισης συνεδριών Ο κωδικός πρόσβασης πρέπει να είναι ισχυρός. Αυτό σηµαίνει ότι πρέπει να έχει ένα ελάχιστο πλήθος χαρακτήρων και να είναι πολύπλοκος, δηλαδή να συνδυάζει πεζά και κεφαλαία γράµµατα, αριθµούς και ειδικούς χαρακτήρες (π.χ. _,!, @). Προτείνεται στους χρήστες να αλλάζουν τον κωδικό πρόσβασής τους σε τακτά χρονικά διαστήµατα και να επιλέγουν κάθε φορά έναν διαφορετικό. Προτείνεται στο χρήστη να περιορίζεται σε συγκεκριµένο αριθµό προσπαθειών σύνδεσης (login), για συγκεκριµένο χρονικό διάστηµα. Επίσης, προτείνεται να καταγράφονται επαναλαµβανόµενες προσπάθειες ανεπιτυχούς σύνδεσης και να ενηµερώνεται ο χρήστης γι αυτό. Τέλος, προτείνεται στο χρήστη, όταν αλλάζει κωδικό πρόσβασης, να παρέχει και τον παλαιό, για λόγους επαλήθευσης. Η διαδικασία σύνδεσης, για να είναι κρυπτογραφηµένη, πρέπει να χρησιµοποιεί τεχνικές όπως το πρωτόκολλο Secure Socket Layer (SSL). Το ίδιο ισχύει για το αναγνωριστικό της συνεδρίας, το οποίο πρέπει να έχει µεγάλο µήκος χαρακτήρων, να είναι πολύπλοκο και µε τυχαίους χαρακτήρες, ώστε κάποιος να δυσκολευτεί να το µαντέψει. Επίσης, καλό είναι να αλλάζει υποχρεωτικά, αν γίνει µετάβαση σε SSL και να µην επιλέγεται ποτέ από το χρήστη. Αν πρέπει να παρουσιαστεί µια λίστα χρηστών σε έναν ιστότοπο, συνίσταται η χρήση ψευδωνύµου, που να αντιστοιχεί στον πραγµατικό λογαριασµό χρήστη, ώστε να µην µπορεί να χρησιµοποιηθεί για είσοδο από τρίτους. Τα δεδοµένα αυθεντικοποίησης και συνεδρίας πρέπει να υποβάλλονται µε τη µέθοδο POST, ώστε να µη φαίνονται στον υπερσύνδεσµο. Επίσης, οι σελίδες αυθεντικοποίησης (authentication pages) δεν πρέπει να βρίσκονται στην κρυφή µνήµη (cached), για να µην είναι προσβάσιµες µε το κουµπί «πίσω». Σε έναν ιστότοπο πρέπει, κατά το δυνατόν, να αποφεύγεται η απόλυτη εµπιστοσύνη µεταξύ των στοιχείων του. Για παράδειγµα, το στοιχείο Χ, που αλληλεπιδρά µε ένα άλλο Υ, πρέπει να αυθεντικοποιείται πριν από την αλληλεπίδρασή τους. 11.2.3 Cross-Site Scripting Cross-Site Scripting (CSS ή XSS) ονοµάζεται η αδυναµία µιας εφαρµογής ιστού να επαληθεύσει δεδοµένα προερχόµενα από το χρήστη. Συνήθως, ο κακόβουλος κώδικας εισάγεται µε τη µορφή ενός σεναρίου ενεργειών (script) στη µεριά του φυλλοµετρητή. Συγκεκριµένα, ο επιτιθέµενος µπορεί µέσω των σεναρίων ενεργειών να υποκλέψει συνεδρίες χρηστών, να τροποποιήσει ιστότοπους µε µη επιθυµητό περιεχόµενο, ακόµα και να πάρει τον έλεγχο του φυλλοµετρητή του χρήστη µε τη χρήση κακόβουλου λογισµικού (malware). Μια εφαρµογή είναι ευάλωτη σε επιθέσεις XSS όταν η είσοδος από το χρήστη δεν ελέγχεται µέσω επικύρωσης εισόδου (input validation), πριν αυτή συµπεριληφθεί στην έξοδο που θα δώσει η σελίδα.[7],[8] Στην Εικόνα 11.4 βλέπουµε σχηµατικά τη λογική της επίθεσης XSS.
Εικόνα 11.4 Η επίθεση XSS. Η επίθεση XSS είναι αρκετά δηµοφιλής, δεδοµένου ότι η εκµετάλλευσή της δεν απαιτεί ιδιαίτερη γνώση της εφαρµογής, ενώ διαπερνά οποιοδήποτε µέσο άµυνας, όπως τείχη προστασίας (firewall), ψηφιακές υπογραφές, κρυπτογραφία και εµπιστευτικότητα του ιστότοπου. Από την άλλη µεριά, το θύµα µπορεί δύσκολα να καταλάβει ποια εφαρµογή ιστού ή ποιο ευάλωτο στοιχείο µιας εφαρµογής επέτρεψε την επίθεση XSS. 11.2.3.1. Αντιµετώπιση της επίθεσης XSS Πρέπει να αποφεύγεται η απευθείας τοποθέτηση µη αξιόπιστων δεδοµένων στη σελίδα HTML, εκτός και αν αυτά έχουν περάσει τη διαδικασία επαλήθευσης. Τα περισσότερα πλαίσια εφαρµογής ιστού (Web Application Frameworks/WAF) διαθέτουν µεθόδους επικύρωσης για µη αξιόπιστα δεδοµένα. Στον κώδικα HTML προτείνεται να χρησιµοποιείται η τεχνική αντικατάστασης των χαρακτήρων, µερικοί από τους οποίους αναφέρονται, ενδεικτικά, στον Πίνακα 11.1, µε την οντότητά τους (entity), για την αποφυγή εκτέλεσης κακόβουλου κώδικα. & & < < > > " " ' ' / / Πίνακας 11.1. Αντικατάσταση χαρακτήρων, για την αποφυγή κακόβουλου κώδικα HTML. 11.2.4 Μη ασφαλής άµεση αναφορά σε αντικείµενα Η ευπάθεια της µη ασφαλούς άµεσης αναφοράς σε αντικείµενα εµφανίζεται όταν ο επιτιθέµενος (ο οποίος είναι εξουσιοδοτηµένος) αλλάζει την τιµή µιας παραµέτρου που αναφέρεται σε ένα αντικείµενο του συστήµατος, µε σκοπό αυτή να αναφέρεται σε ένα άλλο αντικείµενο, για την προσπέλαση του οποίου ο ίδιος δεν έχει εξουσιοδότηση. Αυτό συµβαίνει διότι οι εφαρµογές, όταν παράγουν ιστοσελίδες, χρησιµοποιούν συχνά το πραγµατικό όνοµα ενός αντικειµένου ή το κλειδί του. Οι εφαρµογές δεν επαληθεύουν πάντα ότι ο χρήστης έχει πρόσβαση στο αντικείµενο-στόχο, µε συνέπεια να
παρατηρείται µη ασφαλής άµεση αναφορά σε αντικείµενα. Η συνέπεια αυτή θέτει σε κίνδυνο όλα τα δεδοµένα που καθορίζονται από την παράµετρο. Για να διασφαλιστεί η µη τροποποίηση τέτοιων αναφορών από το χρήστη, πρέπει απλώς να επαληθευτεί ότι όλες οι αναφορές σε αντικείµενα έχουν την κατάλληλη προστασία. Αυτό επιτυγχάνεται µέσω του ελέγχου του κώδικα της εφαρµογής και µέσω δοκιµών, αλλά δεν συνίσταται η χρήση αυτοµατοποιηµένων εργαλείων. Παράδειγµα τέτοιας επίθεσης µπορεί να αποτελεί µια κλήση σε βάση δεδοµένων τύπου SQL, όπως αυτή η οποία δίνεται στον Κώδικα 11.1 και αποτελεί εντολή πρόσβασης σε αναγνωριστικά χρηστών (User ID): String test_query = "SELECT * FROM Users WHERE userid =?"; PreparedStatement test_stmt = connection.preparestatement(test_query, ); test_stmt.setstring( 1, request.getparameter("user")); ResultSet result = test_stmt.executequery( ); Κώδικας 11.1 Εντολή SQL, για πρόσβαση σε αναγνωριστικό χρήστη. Ένας επιτιθέµενος, µέσω της τροποποίησης της παραµέτρου user της γραµµής 3, µπορεί να προσπελάσει οποιοδήποτε αναγνωριστικό χρήστη θέλει (εφόσον δεν έχει προστασία η αναφορά στο αντικείµενο user). Ένα παράδειγµα του υπερσυνδέσµου τον οποίο µπορεί να χρησιµοποιήσει ο επιτιθέµενος φαίνεται στον Κώδικα 11.2. http://test.com/test/userinformation?user=anyuser Κώδικας 11.2 Ο υπερσύνδεσµος µε τον οποίο ο επιτιθέµενος αποκτά πρόσβαση. Έτσι, ο επιτιθέµενος, βάζοντας στη θέση του anyuser όποιο αναγνωριστικό θέλει (π.χ. 1), αποκτά πρόσβαση σε όλους τους χρήστες της βάσης. 11.2.4.1 Άµυνα για τη µη ασφαλή άµεση αναφορά σε αντικείµενα Η καλύτερη προστασία µπορεί να προσφερθεί µε έµµεσες αναφορές σε αντικείµενα ανά χρήστη ή ανά συνεδρία. Για παράδειγµα, το κλειδί που έχει το αντικείµενο του συστήµατος στη βάση δεδοµένων δεν πρέπει να φαίνεται στο χρήστη. Θα µπορούσε να χρησιµοποιείται ένα νούµερο (π.χ. από το 1 ως το 5, αν ο χρήστης έχει εξουσιοδότηση για 5 αντικείµενα), το οποίο να φαίνεται, αντί για το κλειδί που έχει το αντικείµενο εσωτερικά στο σύστηµα. Επίσης, θα πρέπει να υπάρχουν µέθοδοι ελέγχου της πρόσβασης, για να διαπιστώνεται εάν ο συγκεκριµένος χρήστης είναι εξουσιοδοτηµένος να χρησιµοποιεί τις αναφορές σε ένα αντικείµενο, ιδίως αν αυτός προέρχεται από µια µη έµπιστη πηγή. 11.2.5 Μη αποτελεσµατικές ρυθµίσεις ασφαλείας Οι επιτιθέµενοι αποκτούν πρόσβαση σε µη χρησιµοποιούµενες σελίδες, προεπιλεγµένους λογαριασµούς και µη προστατευµένα αρχεία και διαδροµές, µε στόχο να αποκτήσουν πληροφορίες για το σύστηµα, όπως και µη εξουσιοδοτηµένη πρόσβαση. Τέτοιου είδους ευπάθεια µπορεί να παρατηρηθεί στην πλατφόρµα λογισµικού, στον εξυπηρετητή ιστού, στον εξυπηρετητή εφαρµογών, στη βάση δεδοµένων και, γενικά, σε οποιοδήποτε σηµείο της στοίβας εφαρµογών. Συνέπειες των µη αποτελεσµατικών ρυθµίσεων ασφαλείας είναι η υποκλοπή ή/και η ανεπιθύµητη τροποποίηση των δεδοµένων. Εποµένως, πρέπει ο προγραµµατιστής να έχει γνώση του συστήµατος, προκειµένου αυτό να είναι προστατευµένο. Οι εφαρµογές, το λειτουργικό σύστηµα και το λοιπό λογισµικό πρέπει να είναι ενηµερωµένα. Οι µη απαραίτητες ρυθµίσεις, όπως οι υπηρεσίες και οι σελίδες που δεν
χρησιµοποιούνται, πρέπει να είναι απενεργοποιηµένες. Επίσης, πρέπει να είναι απενεργοποιηµένοι οι προεπιλεγµένοι λογαριασµοί και, στο πλαίσιο των εφαρµογών ιστού, όπως στο Struts, πρέπει να είναι ενεργοποιηµένες οι απαραίτητες ρυθµίσεις ασφαλείας. Παράδειγµα περίπτωσης µη αποτελεσµατικών ρυθµίσεων ασφαλείας αποτελεί η διατήρηση των προεπιλεγµένων στοιχείων εισόδου (όνοµα χρήστη και συνθηµατικό) που έχει ο εξυπηρετητής µιας διαδικτυακής εφαρµογής σε όσες σελίδες αφορούν τη διαχείρισή του. Ο επιτιθέµενος, αν ανακαλύψει τις σελίδες αυτές και αν τα στοιχεία εισόδου είναι τα προεπιλεγµένα, τότε αποκτά πρόσβαση στον εξυπηρετητή και µπορεί να πάρει τον έλεγχό του. 11.2.5.1. Αντιµετώπιση των µη αποτελεσµατικών ρυθµίσεων ασφαλείας Για την αντιµετώπιση των απειλών από µη αποτελεσµατικές ρυθµίσεις ασφαλείας, µπορεί να ληφθούν, µη περιοριστικά, τα εξής µέτρα: Ρύθµιση όλων των προϊόντων λογισµικού και όλων των περιβαλλόντων παραγωγής µε τον ίδιο τρόπο σε επίπεδο ασφάλειας και χρήση διαφορετικού κωδικού πρόσβασης για την είσοδο σε καθένα από αυτά. Περιοδική ενηµέρωση (update) και εγκατάσταση επιδιορθώσεων (patches) σε όλο το λογισµικό. Εγκαθίδρυση µιας ισχυρής αρχιτεκτονικής ασφάλειας, η οποία να διαχωρίζει µεταξύ τους τα διαφορετικά µέρη. Τακτικοί έλεγχοι, για τον εντοπισµό ελαττωµατικών ρυθµίσεων ασφαλείας ή τυχόν παραλείψεων εγκατάστασης ενηµερώσεων και επιδιορθώσεων. 11.2.6. Έκθεση ευαίσθητων δεδοµένων Όταν ένας επιτιθέµενος αποκτήσει πρόσβαση σε ευαίσθητα δεδοµένα, όπως σε λογαριασµούς ηλεκτρονικού ταχυδροµείου (e-mail), συνθηµατικά και κωδικούς πρόσβασης, προσωπικά δεδοµένα και αριθµούς πιστωτικών καρτών ή σε αντίγραφα ασφαλείας αυτών, τότε έχουµε την έκθεση των ευαίσθητων δεδοµένων. Προκειµένου οι εφαρµογές ιστού να προστατέψουν τα ευαίσθητα δεδοµένα τους στην περίπτωση που ο επιτιθέµενος έρθει σε επαφή µε αυτά, χρησιµοποιούν κρυπτογραφικές µεθόδους. Ο επιτιθέµενος δεν αποκρυπτογραφεί, συνήθως, τα δεδοµένα απευθείας, αλλά κλέβει κλειδιά, πραγµατοποιεί δικτυακές επιθέσεις τύπου ενδιάµεσου (man in the middle) και υποκλέπτει δεδοµένα σε µορφή κειµένου (δηλαδή, µη κρυπτογραφηµένα) από τον εξυπηρετητή ή το φυλλοµετρητή. Η ευπάθεια αυτή οφείλεται κυρίως στη µη κρυπτογράφηση των ευαίσθητων δεδοµένων και στη χρήση µη ισχυρών αλγόριθµων κρυπτογράφησης και µη ισχυρών συναρτήσεων κατακερµατισµού, όσον αφορά τους κωδικούς πρόσβασης. Είναι εύκολο να ανιχνευθούν ευαίσθητα δεδοµένα στο φυλλοµετρητή, αλλά δεν είναι εύκολο να ανιχνευτούν στον εξυπηρετητή, εξαιτίας της περιορισµένης πρόσβασης σε αυτόν. Ως αποτέλεσµα, µπορεί να εκτεθούν ευαίσθητα δεδοµένα. Για να εντοπιστούν τυχόν αδυναµίες έκθεσης ευαίσθητων δεδοµένων, εξετάζονται τα ακόλουθα: Αν τα ευαίσθητα δεδοµένα είναι αποθηκευµένα σε µορφή απλού κειµένου, συµπεριλαµβανοµένων των αντιγράφων ασφαλείας τους. Αν τα δεδοµένα µεταφέρονται σε µορφή απλού κειµένου, δηλαδή χωρίς κρυπτογράφηση, και αν µεταφέρονται µέσω του εσωτερικού δικτύου ή του διαδικτύου, που είναι και το πιο επικίνδυνο. Αν χρησιµοποιούνται αδύναµοι ή µη σύγχρονοι αλγόριθµοι κρυπτογράφησης. Αν χρησιµοποιούνται αδύναµα κρυπτογραφικά κλειδιά και αν γίνεται κακή διαχείρισή τους.
Αν λείπουν κατευθυντήριες γραµµές ασφαλείας στους φυλλοµετρητές όταν στέλνονται ή λαµβάνονται ευαίσθητα δεδοµένα. Παράδειγµα έκθεσης ευαίσθητων δεδοµένων είναι το εξής[9]: Τον Μάρτιο του 2008, εκτέθηκαν 134 εκατοµµύρια αριθµοί πιστωτικών καρτών, που χρησιµοποιήθηκαν στην εταιρεία συστηµάτων πληρωµών Heartland. Έγινε αρχικά επίθεση έγχυσης SQL και οι επιτιθέµενοι εγκατέστησαν λογισµικό κατασκοπείας (spyware) στους εξυπηρετητές της εταιρείας. 11.2.6.1 Άµυνα για την έκθεση των ευαίσθητων δεδοµένων Για την προστασία των ευαίσθητων δεδοµένων και την άµυνα στις αντίστοιχες επιθέσεις, θα πρέπει αυτά να κρυπτογραφούνται. Τα µη απαραίτητα ευαίσθητα δεδοµένα πρέπει να διαγράφονται, διότι έτσι δεν θα υπάρχουν και δεν θα είναι δυνατόν να κλαπούν. Πρέπει να χρησιµοποιούνται ισχυροί αλγόριθµοι κρυπτογράφησης και να γίνεται σωστή διαχείριση των κλειδιών. Για την αποτελεσµατικότερη προστασία των κλειδιών, είναι προτιµότερο αυτά να δηµιουργούνται εκτός σύνδεσης και η αποθήκευση ή η µετάδοσή τους να γίνεται µέσω ασφαλών καναλιών. Πρέπει να αποφεύγεται η χρήση αλγόριθµων, όπως είναι οι SHA1 και MD5, καθώς θεωρούνται αδύναµοι. Οι κωδικοί πρόσβασης πρέπει να προστατεύονται µε αλγόριθµους που χρησιµοποιούνται αποκλειστικά γι αυτόν το σκοπό, όπως είναι ο scrypt. Προτείνεται η απενεργοποίηση της αυτόµατης συµπλήρωσης (auto-complete) σε φόρµες που συλλέγουν ευαίσθητα δεδοµένα και της κρυφής µνήµης για σελίδες οι οποίες περιέχουν ευαίσθητα δεδοµένα. 11.2.6.2. Κρυπτογραφία και ψηφιακά πιστοποιητικά Για την αυθεντικοποίηση του ιδιοκτήτη µιας πληροφοριακής οντότητας, µπορεί να χρησιµοποιηθεί η ψηφιακή υπογραφή, η οποία, ανάλογα µε το ισχύον δίκαιο για τα ηλεκτρονικά έγγραφα, µπορεί να ενέχει θέση ιδιόχειρης υπογραφής. Οι χρήστες µπορεί να διαθέτουν ψηφιακά πιστοποιητικά, τα οποία θα πρέπει να τα προστατεύουν από υποκλοπή, προκειµένου να χρησιµοποιούνται για:[10] ασφαλή επικοινωνία, όπως µέσω ηλεκτρονικού ταχυδροµείου (µε υπογραφή και κρυπτογράφηση), ψηφιακή υπογραφή και κρυπτογράφηση ηλεκτρονικών αρχείων, ασφαλή προσδιορισµό της ηλεκτρονικής ταυτότητας και έλεγχο πρόσβασης σε εφαρµογές. Τα ψηφιακά πιστοποιητικά µπορεί να είναι δύο ειδών: o ψηφιακό πιστοποιητικό κρυπτογράφησης, για χρήση σε εφαρµογές κρυπτογράφησης, o ψηφιακό πιστοποιητικό υπογραφής-αυθεντικοποίησης, για χρήση σε εφαρµογές ψηφιακής υπογραφής ηλεκτρονικών εγγράφων και για επιβεβαίωση της ταυτότητας του χρήστη κατά την ηλεκτρονική πρόσβασή του σε ελεγχόµενα σηµεία. 11.2.7. Έλλειψη λειτουργίας ελέγχου επιπέδου πρόσβασης O επιτιθέµενος, όταν δεν υπάρχει λειτουργία για τον έλεγχο του επιπέδου πρόσβασης του κάθε χρήστη, αλλάζει τον υπερσύνδεσµο ή µια παράµετρο σε µια λειτουργία που απαιτεί αυξηµένα δικαιώµατα χρήσης. Με αυτόν τον τρόπο, ανώνυµοι χρήστες µπορούν να προσπελάσουν ιδιωτικές συναρτήσεις, οι οποίες, επί της ουσίας, δεν προστατεύονται. Οι εφαρµογές δεν προστατεύουν πάντα τις λειτουργίες τους αποτελεσµατικά. Κάποιες φορές, η προστασία των λειτουργιών του επιπέδου πρόσβασης υλοποιείται µέσω ρυθµίσεων ασφαλείας, ενώ υπάρχει και περίπτωση οι ρυθµίσεις αυτές να µην είναι σωστές. Επίσης, οι προγραµµατιστές ξεχνούν κάποιες φορές να ελέγχουν τον κώδικα για πιθανά κενά
ασφαλείας. Γενικά, ο εντοπισµός αυτής της αδυναµίας είναι εύκολος. Ωστόσο, το δύσκολο είναι να ταυτοποιηθεί ποιοι υπερσύνδεσµοι ή ποιες λειτουργίες υπάρχουν στο σύστηµα και είναι ευάλωτοι σε επιθέσεις. Προκειµένου να ελεγχθεί εάν µια εφαρµογή είναι ευάλωτη στην εν λόγω απειλή, πρέπει να προσεχθούν τα ακόλουθα: αν το περιβάλλον διεπαφής της µπορεί να καταστήσει εφικτή την περιήγηση σε µη εξουσιοδοτηµένες συναρτήσεις, αν λείπει η αυθεντικοποίηση από την πλευρά του εξυπηρετητή ή αν λείπουν, εν γένει, έλεγχοι εξουσιοδότησης, αν υπάρχουν έλεγχοι από την πλευρά του εξυπηρετητή που να βασίζονται σε πληροφορίες από την πλευρά του επιτιθέµενου. Χρησιµοποιώντας έναν εξυπηρετητή διαµεσολάβησης (proxy server), για περιήγηση στη σελίδα της εφαρµογής, µε ρόλο υψηλού επιπέδου πρόσβασης αρχικά και χαµηλότερου επιπέδου πρόσβασης στη συνέχεια, ενώ οι αποκρίσεις του εξυπηρετητή ούτε διαφέρουν, ούτε προσαρµόζονται ανάλογα µε τα δικαιώµατα των ρόλων, τότε υπάρχει πιθανότητα η εφαρµογή να παρουσιάζει την ευπάθεια της έλλειψης λειτουργίας ελέγχου επιπέδου πρόσβασης. Η χρήση αυτοµατοποιηµένων εργαλείων ανίχνευσης ευπαθειών δεν είναι αποτελεσµατική για την ανίχνευση ευπαθειών αυτού του είδους. Έστω ο υπερσύνδεσµος: http://test.com/test/showuserinfo. Αν χρειάζεται αυθεντικοποίηση του χρήστη για την πρόσβαση σε αυτόν και κάποιος µη αυθεντικοποιηµένος χρήστης αποκτήσει πρόσβαση, τότε προκύπτει έλλειψης λειτουργίας ελέγχου του επιπέδου πρόσβασης. 11.2.7.1. Μέτρα αντιµετώπισης της έλλειψης λειτουργίας ελέγχου του επιπέδου πρόσβασης Η εφαρµογή πρέπει να έχει ένα αποτελεσµατικό τµήµα εξουσιοδότησης, το οποίο να καλείται από τις επιχειρησιακές λειτουργίες. Γενικότερα, η ενηµέρωση και οι έλεγχοι ασφαλείας της εφαρµογής πρέπει να γίνονται εύκολα. Οι µηχανισµοί ασφαλείας πρέπει, από προεπιλογή, να αρνούνται την πρόσβαση, απαιτώντας καθορισµένες εγκρίσεις σε αυστηρά καθορισµένους ρόλους. Αν η συνάρτηση συµπεριλαµβάνεται στη ροή εργασίας, απαιτείται, πριν επιτραπεί η πρόσβαση σε αυτήν, να ελέγχεται εάν οι καταστάσεις είναι οι σωστές. 11.2.7.2 Δικαιώµατα χρήσης και εξουσιοδοτήσεις πρόσβασης Το βασισµένο σε ρόλους µοντέλο ελέγχου πρόσβασης Πέρα από την έννοια της αυθεντικοποίησης, υπάρχει και η έννοια των εξουσιοδοτήσεων στην πρόσβαση των πληροφοριακών πόρων, δηλαδή των δικαιωµάτων που έχει ένας χρήσης να εκτελεί κάποια λειτουργία πάνω σε κάποιον πόρο. Αυτές οι εξουσιοδοτήσεις πρέπει να είναι καλά ορισµένες, ώστε να µην παρατηρείται το φαινόµενο ένας χρήστης να εκτελεί εργασίες που δεν του αναλογούν ή δεν του επιτρέπονται. Επίσης, πρέπει να µην µπορεί ένας πιθανός επιτιθέµενος, εφόσον αποκτήσει πρόσβαση σε κάποιον λογαριασµό, να εκτελέσει ενέργειες µε αυξηµένα δικαιώµατα. Έτσι, περιορίζεται το όποιο κόστος από τις κακόβουλες ενέργειες που µπορεί να κάνει ο επιτιθέµενος. Σε αυτήν την κατεύθυνση, έχει αναπτυχθεί η τεχνική του βασισµένου σε ρόλους ελέγχου πρόσβασης (Role-Based Access Control/RBAC). Το RBAC χρησιµοποιείται ευρέως στη λειτουργία των εφαρµογών, δεδοµένου ότι µειώνει σηµαντικά την πολυπλοκότητα και το κόστος διαχείρισης της ασφάλειας.[9] Επί της ουσίας, προσφέρει ένα πλαίσιο πρόσβασης και εξουσιοδοτήσεων σε πόρους και διαδικασίες ενός συστήµατος, προσαρµοζόµενο κάθε φορά στις δοµές και τις απαιτήσεις της επιχείρησης ή του οργανισµού για την οποία αναπτύσσεται. Στο µοντέλο RBAC, κάθε χρήστης µπορεί να διαδραµατίζει περισσότερους του ενός ρόλους µέσα στην επιχείρηση ή τον οργανισµό, µε βάση τις αρµοδιότητες και τις υποχρεώσεις του. Αυτό είναι ένα πλεονέκτηµα του µοντέλου RBAC, καθώς αυξάνει την ευελιξία χρήσης του από το ΠΣ. Οι υποχρεώσεις ενός χρήστη συνδέονται µε συγκεκριµένες ενέργειες, για την εκτέλεση των οποίων θα πρέπει ο χρήστης να έχει τα αντίστοιχα
δικαιώµατα. Έτσι, κάθε ρόλος πρέπει να συνδέεται µε κάποια δικαιώµατα, που µπορεί να αφορούν είτε πρόσβαση σε δεδοµένα ή άλλους πληροφοριακούς πόρους είτε εκτέλεση διαδικασιών ή προγραµµάτων. Η διαχείριση των ρόλων σε ένα ΠΣ πραγµατοποιείται συνήθως από το διαχειριστή του, ο οποίος συνιστά έναν ακόµα ρόλο του συστήµατος, µε αυξηµένα δικαιώµατα. Άρα, αυτός που θα αναλάβει τον συγκεκριµένο ρόλο θα πρέπει να έχει τις απαιτούµενες γνώσεις και να λειτουργεί µε µεγάλη υπευθυνότητα. Με το RBAC µπορεί να δηµιουργηθεί ιεραρχία ρόλων, στην οποία ο υποκείµενος ρόλος θα έχει συνήθως λιγότερα δικαιώµατα από τον ανώτερο ιεραρχικά ρόλο. Αυτή η ιεραρχία µπορεί να αντανακλά τη δοµή της επιχείρησης ή του οργανισµού. Με βάση τις απαιτήσεις που πρέπει να έχει ένα µοντέλο ρόλων, τα µοντέλα ελέγχου πρόσβασης κατηγοριοποιούνται ως εξής: Επίπεδο µοντέλο (Flat RBAC), στο οποίο οι χρήστες, οι οποίοι ανήκουν σε ρόλους, και οι ρόλοι, οι οποίοι συνδέονται µε δικαιώµατα πρόσβασης, έχουν σχέση πολλά προς πολλά. Δηλαδή, ένας χρήστης µπορεί να ανήκει σε πολλούς ρόλους, ενώ ένα ρόλο µπορεί να τον έχουν πολλοί χρήστες. Αντίστοιχη είναι και η σχέση δικαιωµάτων-ρόλων. Ιεραρχικό µοντέλο (Hierarchical RBAC), στο οποίο οι ρόλοι ανήκουν σε µια ιεραρχία. Έτσι, µπορεί να υπάρχουν για το ίδιο σύστηµα ρόλοι που να έχουν απεριόριστα δικαιώµατα σε κάποιο υποσύστηµα και ταυτόχρονα ρόλοι που να έχουν περιορισµένα δικαιώµατα. Κατά την ανάπτυξη του µοντέλου αυτού, η συγκεκριµένη ιεραρχία µπορεί είτε να υπονοείται είτε να επιβάλλεται ξεκάθαρα, µέσω δενδρικής δοµής. Μοντέλο µε περιορισµούς (Constrained RBAC), µε το οποίο επιβάλλονται η αυστηρή κατανοµή και ο διαχωρισµός των αρµοδιοτήτων, και, ως εκ τούτου, των δικαιωµάτων πρόσβασης ανάµεσα στους ρόλους και τους χρήστες. Παρότι ένας χρήστης ενδέχεται να έχει περισσότερους του ενός ρόλους, δεν µπορεί ταυτόχρονα να έχει πρόσβαση σε όλα τα δικαιώµατα που προκύπτουν από αυτούς τους διαφορετικούς ρόλους. Συµµετρικό µοντέλο (Symmetric RBAC), το οποίο έχει τα χαρακτηριστικά των προηγούµενων µοντέλων, αλλά καθορίζει ότι, όπως µπορεί να γίνει επισκόπηση των δικαιωµάτων πρόσβασης που έχουν συνδεθεί µε ένα ρόλο, έτσι µπορεί να γίνει επισκόπηση και των ρόλων που έχουν συνδεθεί µε συγκεκριµένο δικαίωµα πρόσβασης. Παρακάτω δίνονται παραδείγµατα ρόλων σε ένα πληροφοριακό διαδικτυακό περιβάλλον µιας επιχείρησης ή ενός οργανισµού: υπεύθυνος εφαρµογής, υπεύθυνος διαχείρισης υπαλλήλων, υπεύθυνος εργασιών τοµέα λογιστηρίου, υπεύθυνος διαχείρισης πελατών, υπεύθυνος διαχείρισης εγγράφων, υπεύθυνος εργασιών τοµέα ανάπτυξης λογισµικού, υποστηρικτικοί υπάλληλοι. 11.2.8. Πλαστογράφηση αίτησης δεδοµένων µεταξύ ιστότοπων Η πλαστογράφηση αίτησης δεδοµένων µεταξύ ιστότοπων (Cross-Site Request Forgery/CSRF ή XSRF) προκύπτει όταν ο επιτιθέµενος δηµιουργεί πλαστογραφηµένες αιτήσεις HTTP και o χρήστης εξαπατάται και τις υποβάλλει. Αυτό γίνεται συνήθως µέσω XSS ή µέσω ετικετών εικόνας (image tags). Ο τύπος της επίθεσης αυτής βασίζεται στη διευκόλυνση που προσφέρουν οι εφαρµογές ιστού στον επιτιθέµενο να προβλέψει τις λεπτοµέρειες συγκεκριµένης ενέργειας. Επειδή οι φυλλοµετρητές στέλνουν αυτόµατα τα διαπιστευτήριά τους, όπως τα cookies συνεδρίας (session cookies), οι επιτιθέµενοι είναι εύκολο να κατασκευάσουν κακόβουλες
ιστοσελίδες, που να δηµιουργούν πλαστογραφηµένες αιτήσεις. Οι αιτήσεις αυτές είναι δύσκολο να διακριθούν από τις πραγµατικές. Ως συνέπεια, ο επιτιθέµενος µπορεί να εκτελέσει οποιαδήποτε ενέργεια βάσει των δικαιωµάτων που έχει ο χρήστης, όπως να κάνει σύνδεση και αποσύνδεση, και να αλλάξει τις λεπτοµέρειες του λογαριασµού. Για να ελεγχθεί αν µια εφαρµογή είναι ευάλωτη στην εν λόγω απειλή, πρέπει να βρεθεί ποιοι σύνδεσµοι και ποιες φόρµες περιέχουν προβλέψιµα κουπόνια (tokens) (συστηµικά αντικείµενα, τα οποία αντιπροσωπεύουν το υποκείµενο που έχει λειτουργίες ελέγχου πρόσβασης), µε σκοπό τη CSRF. Γενικότερα, πρέπει να ελέγχονται οι φόρµες και οι σύνδεσµοι που καλούν λειτουργίες αλλαγής κατάστασης (state-change). Ας υποθέσουµε ότι µια εφαρµογή ιστού επιτρέπει στο χρήστη να υποβάλει µια αίτηση αλλαγής κατάστασης, όπως τη µεταφορά χρηµάτων σε αριθµό λογαριασµού (Κώδικας 11.3). http://test.com/test/transfermoney?amount=1000&destinationacco unt=1234567 Κώδικας 11.3 Ο υπερσύνδεσµος µεταφοράς χρηµάτων σε λογαριασµό. Αν ο επιτιθέµενος ενσωµατώσει τον υπερσύνδεσµο σε µια αίτηση για την εµφάνιση µιας εικόνας, τότε ο χρήστης, όσο ο επιτιθέµενος είναι αυθεντικοποιηµένος στον ιστότοπο test.com, µπορεί, µέσω του υπερσυνδέσµου του Κώδικα 11.4, να καθορίσει άλλον αριθµό λογαριασµού και να µεταφέρει σε δικό του λογαριασµό χρήµατα µέσω της πλαστογραφηµένης αίτησης. <img src="http://test.com/test/transfermoney?amount=1000&destinatio naccount=121212t#" width="0" height="0" /> Κώδικας 11.4 Ο υπερσύνδεσµος της πλαστογραφηµένης αίτησης. 11.2.8.1 Άµυνα για τη CSRF Ένας τρόπος προστασίας από επίθεση CSRF είναι τα ειδικά κουπόνια αυθεντικοποίησης σε κάθε αίτηση (authorization tokens), τα οποία ούτε είναι προκαθορισµένα ή προβλέψιµα, αλλά ούτε µπορεί να επαναχρησιµοποιηθούν. Τα κουπόνια αυθεντικοποίησης είναι µοναδικά για κάθε συνεδρία. Δεν υποβάλλονται αυτόµατα από το φυλλοµετρητή, αλλά εισάγονται από την εφαρµογή σε όλες τις φόρµες. Προτείνεται τα κουπόνια αυθεντικοποίησης να βρίσκονται σε κρυµµένα πεδία, ώστε να µη συµπεριλαµβάνονται στον υπερσύνδεσµο, όπως επίσης να αυθεντικοποιείται ο χρήστης εκ νέου ή να αποδεικνύεται µε κάποιον τρόπο (π.χ. µε τη µέθοδο CAPTCHA) ότι όντως είναι χρήστης, και όχι µηχανή. Οι δοκιµές διείσδυσης (penetration testing) µπορούν να εντοπίσουν σε ικανοποιητικό βαθµό την ευπάθεια αυτή, µε στόχο την εξάλειψή της. Επίσης, από την ενδελεχή εξέταση ενός κώδικα που περιλαµβάνει µηχανισµό αποτροπής επιθέσεων CSRF, µπορεί να διαπιστωθεί εάν αυτός είναι αποτελεσµατικά υλοποιηµένος. 11.2.9. Χρησιµοποίηση στοιχείων µε γνωστές ευπάθειες Ο επιτιθέµενος βρίσκει ένα ευάλωτο στοιχείο µέσω της τεχνικής της ανίχνευσης (scanning) ή της τεχνικής της µη αυτοµατοποιηµένης ανάλυσης. Κατόπιν, παραµετροποιεί όπως θέλει την ευπάθεια και αρχίζει την επίθεση. Γενικότερα, πολλές οµάδες ανάπτυξης λογισµικού παραµελούν να ενηµερώνουν τακτικά το λογισµικό που χρησιµοποιούν. Σε κάποιες περιπτώσεις δεν γνωρίζουν ούτε όλα τα στοιχεία που χρησιµοποιούν, ούτε τις εκδόσεις τους. Επίσης, η εξάρτηση των στοιχείων µεταξύ τους, σε περίπτωση που αυτά δεν είναι ενηµερωµένα, αυξάνει τον κίνδυνο.
Ως συνέπεια, το σύστηµα γίνεται ευάλωτο σε πολλούς τύπους επιθέσεων, όπως στις XSS και έγχυσης. Οι επιπτώσεις µπορεί να είναι από σχετικά µικρές, έως καταστροφικές, µε έκθεση ευαίσθητων δεδοµένων και έλεγχο ολόκληρου του συστήµατος από τον επιτιθέµενο. Γενικότερα, για να διαπιστώσουµε εάν χρησιµοποιούµε ένα στοιχείο µε γνωστές ευπάθειες, πρέπει να ελέγξουµε τις διάφορες αναφορές που δηµιουργούνται από τις εταιρείες λογισµικού. Ωστόσο, οι αναφορές αυτές δεν καθορίζουν πάντα ποιες ακριβώς εκδόσεις παρουσιάζουν συγκεκριµένη ευπάθεια. Επίσης, η αρίθµηση των εκδόσεων λογισµικού από τις εταιρείες δεν είναι πάντα κατανοητή. Σε περίπτωση που υπάρχει στη λίστα ευπαθειών ένα στοιχείο το οποίο χρησιµοποιούµε, οφείλουµε να εξετάσουµε αν όντως αυτό είναι ευάλωτο, ελέγχοντας αν χρησιµοποιείται από τον κώδικα του λογισµικού µε το οποίο δουλεύουµε και αν η ευπάθεια µπορεί να προκαλέσει σηµαντική ζηµιά. Γενικότερα, η αναβάθµιση του λογισµικού σε νεότερες εκδόσεις είναι η βέλτιστη λύση για την αντιµετώπιση στοιχείων µε ευπάθειες, διότι οι εταιρείες λογισµικού δεν διαθέτουν, συνήθως, επιδιορθώσεις για παλαιότερες εκδόσεις, δεδοµένου ότι αυτό απαιτεί κάποιο κόστος συντήρησης. Επίσης, προτείνεται η χρήση εργαλείων που να καταγράφουν όλες τις χρησιµοποιούµενες εκδόσεις λογισµικού, καθώς και τις εξαρτήσεις µεταξύ των διαφόρων στοιχείων. Ο τακτικός έλεγχος των βάσεων δεδοµένων και των σχετικών µε ευπάθειες λιστών ηλεκτρονικής αλληλογραφίας είναι ένα πρόσθετο µέτρο αποφυγής επιτυχηµένων επιθέσεων. Η υιοθέτηση πολιτικών ασφαλείας σχετικών µε τη χρήση στοιχείων, όπως η απαίτηση να ακολουθούνται συγκεκριµένα βήµατα για τη χρησιµοποίηση λογισµικού, καθώς και η πραγµατοποίηση δοκιµών ασφαλείας, είναι από τις συνήθεις πρακτικές που ακολουθούνται στις σύγχρονες επιχειρήσεις. Τέλος, προτείνεται η απενεργοποίηση των ευπαθών λειτουργιών και των στοιχείων που δεν χρησιµοποιούνται. 11.2.10 Μη επικυρωµένες ανακατευθύνσεις και προωθήσεις Ο επιτιθέµενος εξαπατά τους χρήστες, έτσι ώστε αυτοί να µεταβούν σε µια µη επικυρωµένη ανακατεύθυνση (redirect). Επειδή ο υπερσύνδεσµος αφορά έναν έµπιστο ιστότοπο, ο χρήστης µεταβαίνει συνήθως σε αυτόν. Στόχος αυτής της επίθεσης είναι η παράκαµψη των ελέγχων ασφαλείας από τον επιτιθέµενο. Οι εφαρµογές έχουν παρόµοιο τρόπο ανακατεύθυνσης των χρηστών σε εξωτερικές σελίδες ή σε εσωτερικές λειτουργίες. Ο εντοπισµός των µη επικυρωµένων ανακατευθύνσεων γίνεται µε την αναζήτηση ανακατευθύνσεων που να περιλαµβάνουν τον πλήρες υπερσύνδεσµο. Ο εντοπισµός των µη επικυρωµένων προωθήσεων είναι δυσκολότερος, καθώς έχει στόχο εσωτερικές σελίδες. Ως συνέπεια της επίθεσης αυτής, οι µη επικυρωµένες κατευθύνσεις µπορεί να επιχειρήσουν να εγκαταστήσουν κακόβουλο λογισµικό ή να εξαπατήσουν το χρήστη, ώστε να υποκλέψουν τον κωδικό πρόσβασής του και άλλες ευαίσθητες πληροφορίες. Οι µη επικυρωµένες προωθήσεις µπορεί να οδηγήσουν στην παράκαµψη του ελέγχου πρόσβασης. Για να ανιχνευτεί αν µια εφαρµογή είναι ευάλωτη στην εν λόγω απειλή, πρέπει να ανιχνευθούν τα σηµεία του κώδικα στον οποίο υπάρχει η χρήση ανακατευθύνσεων ή προωθήσεων. Αν ο υπερσύνδεσµος ανακατεύθυνσης ή προώθησης δεν επαληθεύεται µέσω κάποιας λευκής λίστας (white list), τότε η εφαρµογή είναι ευάλωτη στην απειλή. Αν ο κώδικας δεν είναι διαθέσιµος, τότε συνίσταται ο έλεγχος των παραµέτρων για οµοιότητά τους µε µέρος της ανακατεύθυνσης ή µέρος του υπερσυνδέσµου της ανακατεύθυνσης. Η άµυνα για την αντιµετώπιση µη επικυρωµένων ανακατευθύνσεων και προωθήσεων εξασφαλίζεται µε τη µη χρησιµοποίηση ανακατευθύνσεων και προωθήσεων, αν αυτό είναι εφικτό. Αν δεν είναι εφικτό, τότε πρέπει στον υπερσύνδεσµο να µη φαίνονται οι παράµετροι που δίνει ο χρήστης. Αν πρέπει να φαίνονται οι παράµετροι που δίνει ο χρήστης, τότε πρέπει να εξασφαλιστεί ότι αυτές είναι έγκυρες και ότι ο χρήστης έχει την απαραίτητη εξουσιοδότηση. Προτείνεται να χρησιµοποιείται µια τιµή αντιστοίχισης για αυτές τις
παραµέτρους, και όχι ο πραγµατικός υπερσύνδεσµος ή µέρος αυτού. Ο υπερσύνδεσµος θα µεταφράζεται από κατάλληλο κώδικα στην πλευρά του εξυπηρετητή. Παράδειγµα µη επικυρωµένης ανακατεύθυνσης και προώθησης είναι να έχει µια σελίδα το σύνδεσµο του Κώδικα 11.5, ο οποίος δέχεται την παράµετρο «site». http://www.test.com/redirect.jsp?site= malicious.com Κώδικας 11.5 Παράδειγµα µη επικυρωµένης ανακατεύθυνσης και προώθησης. Ο επιτιθέµενος µπορεί να βάλει στη θέση της παραµέτρου «site» µια κακόβουλη ιστοσελίδα, που να περιέχει κακόβουλο λογισµικό, στην οποία να ανακατευθύνεται ο χρήστης. 11.2.11 Ενδεικτική λίστα µέτρων ασφαλείας Στη συνέχεια δίνεται στον Πίνακα 11.2 µια ενδεικτική λίστα µε µέτρα ασφαλείας που χρησιµοποιούνται για τη διασφάλιση των εφαρµογών ιστού. Χρήση µηχανισµών αυθεντικοποίησης των χρηστών στις υπηρεσίες και τις εφαρµογές του ΠΣ. Χρήση ισχυρών κωδικών πρόσβασης, όπως η παρακάτω κανονική έκφραση για κωδικούς πρόσβασης: ^.*(?=.{5,})(?=.*\d)(?=.*[A-Za-z])(?=.*[@#$%^+_]).*$. Χρήση λογαριασµών µε περιορισµένα δικαιώµατα, στους οποίους οι χρήστες θα έχουν περιορισµένη άποψη των λειτουργιών µιας εφαρµογής, ανάλογα µε τα δικαιώµατά τους, δηλαδή χρήση ενός µοντέλου χρηστών, ρόλων και δικαιωµάτων πρόσβασης, για τις κατάλληλες εξουσιοδοτήσεις. Καλά σχεδιασµένη διαδικασία εγγραφής νέου χρήστη, όπως µε τη χρήση κλειδάριθµου, στην περίπτωση κρίσιµης εφαρµογής. Πιστοποίηση του χρήστη για κάθε κρίσιµη συναλλαγή ξεχωριστά, όπως µε τη χρήση ειδικών πρόσθετων κωδικών (π.χ. του Transaction Arithmetic Number/ΤΑΝ) ή µε εκ νέου αυθεντικοποίηση. Περιορισµός των δεδοµένων εισόδου, µέσα από τον αναλυτικό έλεγχο της µορφής, του τύπου και του µεγέθους των δεδοµένων εισόδου, µε µηχανισµούς που χρησιµοποιούν κανονικές εκφράσεις ή κανόνες. Χρήση αποθηκευµένων διαδικασιών στη βάση δεδοµένων, µέσα από τις οποίες θα παρέχεται πρόσβαση στα δεδοµένα της εφαρµογής. Σαφής ορισµός των δεδοµένων εισόδου και εξόδου από τη βάση στις αποθηκευµένες διαδικασίες, για την αντιµετώπιση επιθέσεων τύπου XSS/CSS. Λήψη προληπτικών µέτρων από το σύστηµα, όσον αφορά µηνύµατα και πληροφορίες που επιστρέφουν σε χρήστες και µπορεί να αποκαλύπτουν τεχνικά χαρακτηριστικά της υποδοµής/υλοποίησης µέσω λαθών. Για παράδειγµα, πρέπει να γίνεται διαχείριση λαθών ή κωδικοποίηση των δεδοµένων εξόδου, ώστε να αποφεύγεται η αποκάλυψη δεδοµένων του συστήµατος ή ευαίσθητων δεδοµένων από τη σελίδα. Επιλεκτική κρυπτογράφηση ευαίσθητων δεδοµένων, όπως χρήση κατακερµατισµένων κωδικών (hashed passwords), κατά την αποθήκευσή τους στη βάση δεδοµένων, µε τη χρήση ισχυρών αλγόριθµων, αλλά και ψηφιακών πιστοποιητικών Χρήση του πρωτοκόλλου ασφαλείας SSL, για την επίτευξη ασφαλούς και κρυπτογραφηµένης επικοινωνίας. Καταγραφή όλων των ενεργειών σε επίπεδο εφαρµογής (ποιος ενήργησε, πότε, σε ποιο σηµείο της εφαρµογής και ποιες ενέργειες έκανε ακριβώς). Χρήση τεχνικών, όπως είναι το µονό εισαγωγικό (single quote), το διπλό εισαγωγικό (double quote), η πλάγια κάθετος (slash), η άνω τελεία (semi colon), καθώς και άλλων τεχνικών, για την αποφυγή µη εξουσιοδοτηµένης πρόσβασης σε αποθηκευµένα δεδοµένα στο σύστηµα. Περιορισµός και έλεγχος πρόσβασης στις υπηρεσίες ftp, smtp και http, προκειµένου να ανιχνεύονται και να εξουδετερώνονται ιοί και επιβλαβής κώδικας σε συνηµµένα σε ηλεκτρονικά µηνύµατα αρχεία ή σε αρχεία ftp κτλ. Υιοθέτηση προηγµένων µηχανισµών πιστοποίησης για χρήστες και εξοπλισµό, µε τη χρήση ψηφιακών πιστοποιητικών και ψηφιακών υπογραφών. Τακτική ενηµέρωση του λογισµικού, καθώς και εγκατάσταση επιδιορθώσεων ασφαλείας.
Αποφυγή εµφάνισης ευαίσθητων παραµέτρων µέσω των υπερσυνδέσµων. Πίνακας 11.2: Ενδεικτικά µέτρα ασφαλείας για εφαρµογές. 11.3. Πρότυπα και τεχνολογίες ασφαλείας Υπηρεσιών Ιστού Η ασφάλεια στις Υπηρεσίες Ιστού (WS) και, γενικά, στις Υπηρεσιοστρεφείς Αρχιτεκτονικές (Service Oriented Architecture/SOA) περιλαµβάνει τις εξής διαστάσεις:[11] ασφάλεια των µηνυµάτων, εµπιστευτικότητα, κατανεµηµένες πολιτικές πρόσβασης και διαχείριση ταυτοτήτων. Η ασφάλεια των µηνυµάτων περιλαµβάνει τα εξής: εµπιστευτικότητα (confidentiality), προκειµένου να διασφαλιστεί ότι τα δεδοµένα είναι διαθέσιµα µόνο σε εξουσιοδοτηµένους χρήστες, ακεραιότητα (integrity), προκειµένου να διασφαλιστεί ότι τα ανταλλασσόµενα δεδοµένα είναι αξιόπιστα και δεν έχουν αλλοιωθεί από τυχαίες ενέργειες, αυθεντικοποίηση (authentication), προκειµένου να εγγυηθεί ότι το µήνυµα δηµιουργήθηκε όντως από την ταυτότητα που δήλωσε τη δηµιουργία του, και µη αποποίηση ευθύνης (non-repudiation), προκειµένου να εκλείψει η πιθανότητα να αρνηθεί ο αποστολέας ενός µηνύµατος την αποστολή του. Η εµπιστευτικότητα αποτελεί ένα µείζον ζήτηµα ασφαλείας, λόγω της χαλαρής ολοκλήρωσης των συστηµάτων που επιτυγχάνει µια SOA. Επειδή κάθε οντότητα µπορεί να βασίζεται σε κάποια άλλη, για την εκτέλεση µιας λειτουργίας που επιθυµεί, απαιτούνται ο προσδιορισµός πολιτικών εµπιστευτικότητας και η δηµιουργία εµπιστευτικότητας µεταξύ των διαφόρων διαχειριστικών τοµέων ασφαλείας (administration domains). Οι πολιτικές ασφαλείας περιγράφουν ένα µεγάλο φάσµα απαιτήσεων και ικανοτήτων των WS, ενώ ελέγχονται τη στιγµή της αλληλεπίδρασης. Ανάλογα µε τις απαιτήσεις του, κάθε οργανισµός µπορεί να επιλέξει την πολιτική ασφαλείας που θα ακολουθήσει. Σκοπός είναι η επικοινωνία του οργανισµού µε οτιδήποτε πέραν αυτού να πραγµατοποιείται βάσει συγκεκριµένης πολιτικής, ώστε να είναι ασφαλής. Σε σχέση µε τη διαχείριση ταυτοτήτων στις SOA, κάθε χρήστης µπορεί να έχει περισσότερες της µιας ταυτότητες, για διαφορετικούς τοµείς διαχείρισης ή εφαρµογής. Μπορεί να χρειαστεί να αυθεντικοποιείται για είσοδο σε καθένα από τα διαφορετικά συστήµατα ή µπορεί να υπάρχει ενιαία αυθεντικοποίηση, µέσω ενός µηχανισµού τύπου Single-Sign On (SSO), όπως ενός εξυπηρετητή Lightweight Directory Access Protocol (LDAP). Σε κάθε περίπτωση, κρίνεται απαραίτητο να υπάρχει ένα κοινό περιβάλλον ασφαλείας για όλα τα συστήµατα, ώστε να µπορούν να χειρισθούν τις πολλαπλές ταυτότητες χρηστών. Το W3C[12],[11] έχει αναπτύξει µια σειρά από πρότυπα ασφαλείας σχετικά µε τις WS. Εδώ, παρουσιάζουµε µια σειρά από αυτά τα πρότυπα, προκειµένου να προϊδεάσουµε τον αναγνώστη για τη συγκεκριµένη σηµαντική προσπάθεια. Συγκριµένα, υπάρχει τo πρότυπο WS Security, το οποίο: περιγράφει τις µεταβολές που έχουν γίνει στην ανταλλαγή µηνυµάτων µέσω του Simple Object Access Protocol (SOAP), παρέχει ακεραιότητα και αυθεντικοποίηση του µηνύµατος µέσω υπογραφής XML (XML Signature) και παρέχει εµπιστευτικότητα του µηνύµατος µε κρυπτογράφηση XML (XML Encryption). Επίσης, το πρότυπο WS Security Policy είναι πολύ σηµαντικό, καθώς καθορίζει τις πολιτικές ασφαλείας και τα ιδιώµατά τους. Εν συντοµία: βασίζεται στο πρότυπο WS Policy, το οποίο περιγράφει την ευρύτερη έννοια της πολιτικής στις WS,
περιγράφει µε ποιο τρόπο αποστολείς και παραλήπτες µπορούν να καθορίσουν τις δικές τους προϋποθέσεις ασφαλείας και τα δικαιώµατά τους, δεν θέτει όρια προϋποθέσεων και δικαιωµάτων στο ίδιο το πρότυπο, και παρέχει ένα µηχανισµό σύνδεσης των πολιτικών υπηρεσιών (service policies), µέσω SOAP µηνυµάτων. Άλλο σηµαντικό πρότυπο είναι το WS Trust, το οποίο παρέχει εµπιστευτικότητα, ενώ ορίζει την ανάγκη για τη δηµιουργία εµπιστευτικότητας πριν από την αλληλεπίδραση µεταξύ της υπηρεσίας και του χρήστη σε ένα κατανεµηµένο υπολογιστικό περιβάλλον. Συγκεκριµένα: είναι προέκταση του προτύπου WS Security, παρέχει µηχανισµούς απόκτησης κουπονιών ασφαλείας και δηµιουργεί σχέσεις εµπιστευτικότητας, και δίνει τη δυνατότητα αλληλεπίδρασης σε διαφορετικά περιβάλλοντα ασφαλείας, χωρίς την ανάγκη σηµαντικών αλλαγών. Από την άλλη πλευρά, η διαχείριση ταυτοτήτων στις WS εξασφαλίζεται µε τα ακόλουθα πρότυπα: Πρότυπο OASIS Security Assertion Markup Language (SAML), το οποίο παρέχει ένα πλαίσιο εργασίας σε µορφή XML, για την ανταλλαγή πιστοποιητικών ασφαλείας µεταξύ αποµακρυσµένων συστηµάτων και εφαρµογών. Πρότυπο Liberty Alliance, το οποίο θέτει ρυθµίσεις για την παροχή ενός γενικού πλαισίου διαχείρισης ταυτοτήτων µεταξύ πολλαπλών τοµέων ασφαλείας (security domains). Τέλος, το πρότυπο WS Federation παρέχει ακεραιότητα και αυθεντικοποίηση σε διαφορετικούς τοµείς ασφαλείας. Συγκεκριµένα: βασίζεται στα πρότυπα WS-Security, WS-Policy και WS-Trust, παρέχει ακεραιότητα και αυθεντικοποίηση του µηνύµατος, µε την XML υπογραφή, και παρέχει µηχανισµούς που επιτρέπουν σε διαφορετικούς τοµείς ασφαλείας να συνδέονται, καταργώντας την εµπιστευτικότητα µεταξύ ταυτοτήτων ή την αυθεντικοποίηση των συµµετεχόντων WS. 11.4 Η ασφάλεια στην Java Στην ενότητα αυτή, παρουσιάζονται συνοπτικά τα χαρακτηριστικά ασφαλείας της γλώσσας προγραµµατισµού Java. Η πλατφόρµα της Java στηρίζεται σε µια δυναµική αρχιτεκτονική ασφαλείας, η οποία βασίζεται σε πρότυπα και υποστηρίζει τη διαλειτουργικότητα. Η αρχιτεκτονική αυτή περιλαµβάνει βιβλιοθήκες για την αυθεντικοποίηση και την εξουσιοδότηση του χρήστη, την κρυπτογράφηση των δεδοµένων κτλ. Επίσης, το µοντέλο ασφαλείας της Java βασίζεται σε ένα παραµετροποιήσιµο περιβάλλον δοκιµών (sandbox), µέσω του οποίου τα προγράµµατα σε Java µπορεί να εκτελούνται µε ασφάλεια, χωρίς να θέτουν σε κίνδυνο το λειτουργικό σύστηµα ή τους χρήστες. Τα χαρακτηριστικά ασφαλείας που αφορούν την πλατφόρµα της Java είναι η αυτόµατη διαχείριση της µνήµης, η ασφαλής φόρτωση των κλάσεων και η επαλήθευση του ενδιάµεσου κώδικα (bytecode), ο οποίος εξασφαλίζει ότι αυτός βασίζεται στις προδιαγραφές της εικονικής µηχανής της Java (Java Virtual Machine/JVM). Σκοπός των ενεργειών αυτών είναι η αποτροπή της εκτέλεσης κακόβουλου κώδικα, ο οποίος θα µπορούσε να διακόψει το περιβάλλον του χρόνου εκτέλεσης (runtime environment). Σχετικά µε την κρυπτογραφία, η Java διαθέτει αρχιτεκτονική, την Java Cryptography Architecture, η οποία παρέχει βιβλιοθήκες που υλοποιούν αλγόριθµους κρυπτογράφησης και παρόµοιες υπηρεσίες, όπως ψηφιακές υπογραφές κώδικες αυθεντικοποίησης µηνυµάτων κτλ. Σχετικά µε την αυθεντικοποίηση και τον έλεγχο πρόσβασης, διαθέτει βιβλιοθήκες όπως η Java Authentication and Authorization Service, η οποία υλοποιεί µηχανισµούς