Κοινόχρηστοι υποτομείς, δύο είσοδοι: ποιος βλέπει ποιες εγγραφές;

Η Κλινική A και η Κλινική B μοιράζονται έναν κώδικα, δύο υποτομείς και ένα μείγμα επισκεπτών από το γραφείο και μέσω VPN. Οι ομάδες δικτύου συνηθίζουν να ρυθμίζουν τις δύο εισόδους ξεχωριστά, και αυτό είναι εντάξει, εφόσον δεν το κάνει η εφαρμογή. Οι έλεγχοι παρακάτω ανήκουν στην εφαρμογή και πρέπει να συμπεριφέρονται πανομοιότυπα ανεξάρτητα από την πόρτα που χρησιμοποίησε το αίτημα.

Πρώτον: το όνομα κεντρικού υπολογιστή ονομάζει μόνο έναν ενοικιαστή

Αντιστοιχίστε το ζητούμενο όνομα κεντρικού υπολογιστή με μια αντιστοίχιση που συντηρεί ο διαχειριστής, και απορρίψτε οτιδήποτε άγνωστο. Χρησιμοποιήστε την επικυρωμένη τιμή κεντρικού υπολογιστή του πλαισίου αντί για την ακατέργαστη κεφαλίδα, ώστε ένα κατασκευασμένο Host να μην μπορεί να εισάγει κλειδί αναζήτησης. Μια επιτυχής αντιστοίχιση λέει στον κώδικα ποια διαμόρφωση ενοικιαστή και ποια επωνυμία να φορτώσει. Δεν λέει τίποτα για το αν ο καλών μπορεί να δει τα δεδομένα αυτού του ενοικιαστή. Κρατήστε το δεύτερο ερώτημα σε ξεχωριστή συνάρτηση με ξεχωριστή είσοδο.

Μια κοινόχρηστη βοηθητική συνάρτηση που επιστρέφει και το πλαίσιο και την άδεια από μία μόνο αναζήτηση ονόματος κεντρικού υπολογιστή είναι η αρχή του σφάλματος.

Δεύτερον: η ιδιότητα μέλους προέρχεται από τη συνεδρία

Αναζητήστε τις ενεργές ιδιότητες μέλους του πιστοποιημένου χρήστη και συγκρίνετε τις με τον ενοικιαστή του πρώτου ελέγχου. Ένας χρήστης που ανήκει και στις δύο κλινικές μπορεί να αλλάξει, αλλά η αλλαγή πρέπει να είναι ρητή ενέργεια καταγεγραμμένη στο πλαίσιο του αιτήματος, όχι συμπέρασμα από το URL. Ένας χρήστης που ανήκει σε μία κλινική και ζητά την άλλη απορρίπτεται, και για λήψεις και για κλήσεις API.

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

Το εύρος των cookies και η ενιαία σύνδεση καθορίζουν πού μπορεί να παρουσιαστεί ένας λογαριασμός. Δεν καθορίζουν τι επιτρέπεται να διαβάσει αυτός ο λογαριασμός.

Τρίτον: το δίκτυο δεν αποδεικνύει τίποτα για το πρόσωπο

Μια πύλη VPN πιστοποιεί μια σήραγγα, και μια δημόσια λίστα επιτρεπόμενων πιστοποιεί ένα εύρος διευθύνσεων. Καμία από τις δύο δεν ταυτοποιεί πρόσωπο. Το NAT συμπτύσσει πολλούς χρήστες σε μία διεύθυνση προέλευσης, και ένα εύρος γραφείου κάνει το ίδιο για όλους στο κτίριο. Αντιμετωπίστε και τα δύο ως γεγονότα μεταφοράς και κρατήστε την εξουσιοδότηση στην εφαρμογή, ή σε μια ενσωμάτωση που δηλώνει ρητά ταυτότητα και ελέγχεται ως τέτοια.

Το DNS είναι ένα τρίτο γεγονός μεταφοράς. Μια ιδιωτική απάντηση χρειάζεται ιδιωτική διαδρομή, και ένα δημόσιο μέτωπο χρειάζεται υποστηριζόμενη διαδρομή προέλευσης. Κανένα από αυτά δεν φέρει άδεια.

Μία φράση για τον τοίχο: το δίκτυο αποφασίζει πώς φτάνει ένα αίτημα, και η εφαρμογή αποφασίζει τι επιτρέπεται να διαβάσει.

Τέταρτον: εκτελέστε τον πίνακα και στις δύο εισόδους

Χρησιμοποιήστε ελεγχόμενους λογαριασμούς για να δοκιμάσετε A στο A, B στο B, A στο B, ένα άγνωστο όνομα κεντρικού υπολογιστή και έναν πιστοποιημένο λογαριασμό χωρίς ιδιότητες μέλους. Το τέταρτο και το πέμπτο πρέπει να αποτυγχάνουν κλειστά και να μην καταφεύγουν ποτέ σε προεπιλεγμένο ενοικιαστή. Εκτελέστε τον ίδιο πίνακα και μέσω της εισόδου VPN, με ένα βάζο συνεδρίας ανά λογαριασμό:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

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

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