Ασφάλεια κώδικα: πώς χτίζεται η προστασία από τον σχεδιασμό
Η ασφάλεια κώδικα δεν επιτυγχάνεται απλώς επειδή η εφαρμογή δεν εμφανίζει εμφανή λάθη. Ένα σύστημα μπορεί να λειτουργεί άψογα για τον νόμιμο χρήστη και ταυτόχρονα να επιτρέπει σε άλλον να δει δεδομένα που δεν του ανήκουν. Ο στόχος είναι να σχεδιάζουμε κανόνες εμπιστοσύνης, να περιορίζουμε δικαιώματα και να ελέγχουμε τι συμβαίνει όταν η είσοδος ή το περιβάλλον δεν είναι όπως αναμενόταν. Η διαχείριση εξαρτήσεων λογισμικού ολοκληρώνει την προστασία των διαδρομών που ελέγχουμε, χωρίς να υποκαθιστά τη δοκιμή της επιχειρησιακής λογικής.
Η αποτελεσματική προσέγγιση ξεκινά πριν από τη σύνταξη μιας λειτουργίας: ποιος επιτρέπεται να κάνει τι, με ποια δεδομένα και τι πρέπει να συμβεί όταν μια ενέργεια απορριφθεί; Όταν οι απαντήσεις γίνουν ελέγξιμες απαιτήσεις, ο έλεγχος ασφάλειας παύει να είναι αόριστη τελική επιθεώρηση.
Ορίστε πρώτα τα όρια εμπιστοσύνης
Κάθε στοιχείο που προέρχεται από πρόγραμμα περιήγησης, εξωτερικό συνεργάτη ή άλλον μη ελεγχόμενο μηχανισμό χρειάζεται αντιμετώπιση ως δυνητικά μη έμπιστο. Αυτό ισχύει ακόμη κι όταν η οθόνη έχει ήδη ελέγξει τη μορφή του πεδίου. Η τελική απόφαση πρέπει να λαμβάνεται από την υπηρεσία που διαθέτει τα κατάλληλα δεδομένα και δικαιώματα.
Σχεδιάζουμε απλό διάγραμμα διαδρομών: χρήστης, διακομιστής, αποθήκη δεδομένων, τρίτες υπηρεσίες. Σημειώνουμε πού αλλάζει ο βαθμός εμπιστοσύνης και ποιον έλεγχο απαιτεί κάθε διέλευση. Η διαδικασία αποκαλύπτει σημεία που συχνά μένουν αόρατα σε μια επιθεώρηση μόνο του ορατού κώδικα.
Ταυτοποίηση δεν σημαίνει εξουσιοδότηση
Το ότι ένας χρήστης έχει συνδεθεί δεν του δίνει δικαίωμα να προσπελάσει οποιαδήποτε εγγραφή. Κάθε λειτουργία που διαβάζει ή αλλάζει πόρους πρέπει να επιβεβαιώνει την εξουσιοδότηση για τον συγκεκριμένο πόρο και τη συγκεκριμένη ενέργεια. Δεν βασιζόμαστε στο ότι η οθόνη κρύβει κάποιο κουμπί· ένας μη εξουσιοδοτημένος χρήστης μπορεί να καλέσει απευθείας την ίδια διαδρομή.
Ενδεικτικός έλεγχος: ένας συνδεδεμένος πελάτης προσπαθεί να ανακτήσει εγγραφή άλλου πελάτη αλλάζοντας ένα αναγνωριστικό. Το αναμενόμενο αποτέλεσμα είναι άρνηση πρόσβασης χωρίς αποκάλυψη ευαίσθητων λεπτομερειών. Αυτή η δοκιμή αφορά την πραγματική πολιτική δικαιωμάτων, όχι την εμφάνιση της διεπαφής.
Επικύρωση δεδομένων σε κάθε κρίσιμο όριο
Ελέγχουμε τύπο, εύρος, μήκος και επιτρεπόμενες τιμές σύμφωνα με την επιχειρησιακή απαίτηση. Ο έλεγχος πρέπει να απορρίπτει σαφώς άκυρες εισόδους, όχι να διορθώνει σιωπηρά κάθε αναπάντεχη μορφή. Στις εντολές προς βάση δεδομένων χρησιμοποιούμε παραμετροποιημένα ερωτήματα, ώστε οι τιμές να μην ερμηνεύονται ως τμήμα της εντολής.
Για περιεχόμενο που εμφανίζεται στην οθόνη, ο ασφαλής τρόπος απόδοσης εξαρτάται από το πλαίσιο χρήσης του. Ένας χαρακτήρας μέσα σε κείμενο έχει διαφορετικό κίνδυνο από τον ίδιο χαρακτήρα μέσα σε χαρακτηριστικό ή διεύθυνση. Γι’ αυτό δεν αρκεί ένας γενικός «καθαρισμός» για κάθε περίπτωση.
Διαχείριση συνθηματικών, διαπιστευτηρίων και κλειδιών
Τα μυστικά πρόσβασης δεν πρέπει να αποθηκεύονται στον δημόσιο κώδικα ούτε να εμφανίζονται σε αρχεία διάγνωσης. Απαιτείται ασφαλής μηχανισμός αποθήκευσης, περιορισμός πρόσβασης ανά υπηρεσία και δυνατότητα αντικατάστασης όταν υπάρχει υποψία έκθεσης. Στα συνθηματικά χρηστών εφαρμόζεται κατάλληλη μονόδρομη προστασία με σύγχρονες παραμέτρους, όχι απλή κρυπτογράφηση που μπορεί να αναστραφεί κατά βούληση.
Ο τρόπος μεταφοράς δεδομένων και η διάρκεια ισχύος των διακριτικών αποτελούν μέρος του ίδιου σχεδιασμού. Αναρωτιόμαστε τι μπορεί να κάνει κάποιος αν αποκτήσει ένα διακριτικό και για πόσο χρόνο, ώστε τα δικαιώματα και η ανάκληση να έχουν συγκεκριμένο νόημα.
Κίνδυνοι από βιβλιοθήκες και εξαρτήσεις
Μια εφαρμογή περιλαμβάνει συνήθως περισσότερα από τον κώδικα της ομάδας. Βιβλιοθήκες, πρόσθετα και εργαλεία εγκατάστασης αποκτούν θέση στην αλυσίδα εμπιστοσύνης. Κρατάμε καταγραφή των άμεσα και έμμεσα χρησιμοποιούμενων εξαρτήσεων, ελέγχουμε τις ενημερώσεις τους και αφαιρούμε όσες δεν χρησιμοποιούνται.
Μια αλλαγή έκδοσης δεν περνά απευθείας στην παραγωγή επειδή αναφέρεται ως «διορθωτική». Χρειάζεται έλεγχος συμβατότητας, καταγραφή της μεταβολής και δυνατότητα επαναφοράς. Για ιστότοπους με πολλά πρόσθετα, η ασφάλεια ιστοσελίδων σχετίζεται και με τη διακυβέρνηση αυτού του επιπλέον κώδικα.
Πώς λειτουργεί μια ουσιαστική ανασκόπηση
Η ανασκόπηση αλλαγών πρέπει να εξετάζει το νόημα: ποιο δικαίωμα προστέθηκε, ποια πληροφορία εκτίθεται, τι συμβαίνει με λάθος δεδομένα και πώς αποτυγχάνει η υπηρεσία. Οι αυτόματοι έλεγχοι εντοπίζουν ορισμένες γνωστές κατηγορίες κινδύνου, αλλά δεν καταλαβαίνουν πάντοτε αν ένας χρήστης βλέπει παραγγελία άλλου ή αν μια επιχειρησιακή απόφαση παρακάμπτεται.
Αξιολογούμε χωριστά τη χρήση τεχνητής νοημοσύνης στον έλεγχο κώδικα. Μπορεί να επισημάνει ύποπτα σημεία, όμως δεν αποκτά δικαίωμα έγκρισης παραγωγικών αλλαγών. Η τελική ευθύνη παραμένει σε πραγματικό τεχνικό υπεύθυνο.
Αρνητικές δοκιμές με σημασία
Μια εφαρμογή δεν θεωρείται ασφαλής επειδή ο χρήστης μπορεί να ολοκληρώσει σωστά την αγορά ή την υποβολή. Δοκιμάζουμε ληγμένη συνεδρία, απουσία εξουσιοδότησης, παραποιημένο αναγνωριστικό, υπέρβαση ορίων, επαναλαμβανόμενη ενέργεια και αποτυχία εξωτερικής υπηρεσίας. Για κάθε περίπτωση περιγράφουμε τη σωστή απορριπτική συμπεριφορά και τις ελάχιστες πληροφορίες που πρέπει να επιστραφούν.
Οι δοκιμές δεν εκτελούνται αυθαίρετα σε συστήματα τρίτων. Απαιτείται έγκριση, προκαθορισμένο πεδίο ελέγχου και προστασία πραγματικών δεδομένων, ειδικά όταν οι δοκιμές επηρεάζουν λογαριασμούς ή διαθέσιμες υπηρεσίες.
Χρησιμοποιήστε πολλαπλές μεθόδους επαλήθευσης
Ο στατικός έλεγχος εξετάζει τον κώδικα χωρίς να χρειάζεται πλήρης εκτέλεση. Ο δυναμικός έλεγχος παρατηρεί την εφαρμογή σε λειτουργία. Η επιθεώρηση εξαρτήσεων καλύπτει γνωστούς κινδύνους εξωτερικών τμημάτων, ενώ η χειροκίνητη εξέταση προσπαθεί να εντοπίσει αστοχίες σχεδιασμού ή λογικής. Καμία μέθοδος μόνη της δεν εγγυάται καθολική προστασία.
Είναι προτιμότερο να υπάρχουν μερικές καλά συνδεδεμένες μέθοδοι με σαφείς υπευθύνους, παρά πολλές αναφορές με ευρήματα που κανείς δεν αξιολογεί. Η σοβαρότητα ενός θέματος κρίνεται με βάση τη δυνατότητα εκμετάλλευσης και τον πραγματικό αντίκτυπο στο συγκεκριμένο σύστημα.
Πρακτικό φύλλο ελέγχου πριν από δημοσίευση
- Υπάρχει εξουσιοδότηση για κάθε ανάγνωση και μεταβολή ευαίσθητου πόρου;
- Ελέγχεται η είσοδος στον διακομιστή με τους σωστούς κανόνες;
- Απουσιάζουν μυστικά από κώδικα, καταγραφές και δημοσιευμένα αρχεία;
- Είναι οι εξαρτήσεις γνωστές, απαραίτητες και ελεγχόμενες;
- Υπάρχουν αρνητικές δοκιμές και ανεξάρτητη ανθρώπινη έγκριση;
- Είναι διαθέσιμη ασφαλής διαδικασία απόσυρσης ή επαναφοράς;
Το φύλλο λειτουργεί ως υπενθύμιση, όχι ως πιστοποίηση. Αν μία απάντηση είναι άγνωστη, χρειάζεται διερεύνηση και τεκμήριο, όχι αυτόματη θετική αξιολόγηση.
Από την ευπάθεια στη διόρθωση
Όταν εντοπίζεται αδυναμία, περιορίζουμε πρώτα τον πραγματικό κίνδυνο και προστατεύουμε τα δεδομένα. Στη συνέχεια αναπαράγουμε το πρόβλημα με ελεγχόμενο παράδειγμα, αλλάζουμε το μικρότερο κατάλληλο τμήμα και επανεκτελούμε τόσο τον αρνητικό έλεγχο όσο και τις βασικές λειτουργίες. Η τεκμηρίωση περιλαμβάνει το αίτιο και τον κανόνα που αποτρέπει την επιστροφή του προβλήματος.
Ο επόμενος έλεγχος δεν ξεκινά από μηδενική μνήμη. Οι συχνές κατηγορίες ευρημάτων μετατρέπονται σε κανόνες ανασκόπησης και δοκιμές που συνοδεύουν κάθε επόμενη αλλαγή.
Πότε αναθεωρούμε το μοντέλο προστασίας
Οι έλεγχοι ασφάλειας δεν μένουν ίδιοι όταν αλλάζουν οι ρόλοι χρηστών, προστίθενται υπηρεσίες ή μεταφέρονται δεδομένα σε νέο υποσύστημα. Σε τέτοιες αλλαγές επαναξιολογούμε τη διαδρομή εμπιστοσύνης και τις επιτρεπόμενες ενέργειες. Ο έλεγχος εξουσιοδότησης χρειάζεται να παραμένει σαφής ακόμη κι αν ο τρόπος ταυτοποίησης αλλάξει. Η επικύρωση εισόδου εφαρμόζεται σε κάθε νέα είσοδο δεδομένων, ενώ η διαχείριση των μυστικών πρόσβασης ενημερώνεται όταν δημιουργείται νέα εξωτερική εξάρτηση.
Συχνές ερωτήσεις για ασφαλή ανάπτυξη
Ποια είναι η πρώτη προτεραιότητα στην ασφάλεια κώδικα;
Να καταγραφούν ευαίσθητα δεδομένα, ενέργειες και όρια εμπιστοσύνης, ώστε να γνωρίζουμε τι πρέπει να προστατευτεί.
Αρκεί ο έλεγχος στοιχείων στην οθόνη;
Όχι. Ο διακομιστής πρέπει να επιβάλει τους δικούς του κανόνες ακόμα και όταν παρακάμπτεται η οθόνη.
Πώς προστατεύονται τα μυστικά πρόσβασης;
Με ελεγχόμενη αποθήκευση, ελάχιστα δικαιώματα, αποφυγή καταγραφής και προβλέψιμη διαδικασία αντικατάστασης.
Τι εξετάζουμε στις βιβλιοθήκες τρίτων;
Προέλευση, αναγκαιότητα, ενημερώσεις, γνωστούς κινδύνους και αντίκτυπο σε λειτουργίες της εφαρμογής.
Μπορεί ο αυτόματος σαρωτής να εγγυηθεί ασφάλεια;
Όχι. Είναι ένα εργαλείο εντοπισμού συγκεκριμένων προβλημάτων και συμπληρώνεται από ανθρώπινη αξιολόγηση και πραγματικές δοκιμές.
Πότε πρέπει να γίνεται έλεγχος δικαιωμάτων;
Σε κάθε πρόσβαση ή μεταβολή προστατευμένου πόρου, όχι μόνο κατά την πρώτη σύνδεση χρήστη.