Βέλτιστες πρακτικές για την κατασκευή ασφαλών API

από τον Rakesh Talanki και τον Vidheer Gadikota

Το API (περιβάλλον προγραμματισμού εφαρμογών), οι σχεδιαστές και οι προγραμματιστές κατανοούν γενικά τη σημασία της τήρησης των αρχών σχεδιασμού κατά την υλοποίηση διεπαφής. Κανείς δεν θέλει να σχεδιάσει ή να εφαρμόσει ένα κακό API!

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

Οι προγραμματιστές θα πρέπει να θυμούνται να φορούν το καπέλο ενός hacker API πριν από την ανάπτυξη. Εάν ένας προγραμματιστής παραμελήσει να εντοπίσει τις ευπάθειες σε ένα API, το API μπορεί να γίνει μια ανοιχτή πύλη για κακόβουλη δραστηριότητα.

Εντοπισμός και επίλυση ευπάθειας API

Ένα API μπορεί να λειτουργήσει για ή κατά του παρόχου ανάλογα με το πόσο καλά ο πάροχος έχει καταλάβει και έχει εφαρμόσει τις απαιτήσεις των χρηστών του API. Αν μια εταιρεία κατασκευάζει ένα εξαιρετικά ασφαλές API, μπορεί να καταλήξει πολύ δύσκολο στη χρήση. Μια λεπτή ισορροπία πρέπει να επιτευχθεί μεταξύ του σκοπού ενός API και της ευκολίας κατανάλωσης. Σε αυτό το άρθρο, θα εξετάσουμε μερικά από τα τρωτά σημεία API που αντιμετωπίσαμε μέσω της δουλειάς μας, ως μέρος της ομάδας Apigee της Google, συμπεριλαμβανομένου του τρόπου με τον οποίο θα μπορούσαν να αποφευχθούν αυτά τα τρωτά σημεία.

Ενέσεις

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

Τον Οκτώβριο του 2014, για παράδειγμα, το Drupal ανακοίνωσε μια ευπάθεια SQL ένεσης που επέτρεψε στους επιτιθέμενους να έχουν πρόσβαση σε βάσεις δεδομένων, κώδικα και αρχεία καταλόγων. Η επίθεση ήταν τόσο σοβαρή ώστε οι επιτιθέμενοι μπορεί να έχουν αντιγράψει όλα τα δεδομένα από τα sites των πελατών. Υπάρχουν πολλοί τύποι απειλών για έγχυση, αλλά οι πιο συνηθισμένες είναι η ένεση SQL, η ένεση RegEx και η ένεση XML. Πολλές φορές, έχουμε δει τα API να ζουν χωρίς προστασία από απειλές - δεν είναι ασυνήθιστο.

API χωρίς έλεγχο ταυτότητας

Ένα API που έχει κατασκευαστεί χωρίς προστασία από κακόβουλες απειλές μέσω ελέγχου ταυτότητας αντιπροσωπεύει μια αποτυχία σχεδιασμού API που μπορεί να απειλήσει βάσεις δεδομένων ενός οργανισμού. Η παράβλεψη της σωστής πιστοποίησης - ακόμα και αν χρησιμοποιείται κρυπτογράφηση στρώματος μεταφοράς (TLS) - μπορεί να προκαλέσει προβλήματα. Με έναν έγκυρο αριθμό κινητού τηλεφώνου σε ένα αίτημα API, για παράδειγμα, οποιοδήποτε άτομο θα μπορούσε να αποκτήσει προσωπικές διευθύνσεις ηλεκτρονικού ταχυδρομείου και δεδομένα αναγνώρισης συσκευής. Οι ισχυροί μηχανισμοί ελέγχου ταυτότητας και εξουσιοδότησης όπως το OAuth / OpenID Connect, σε συνδυασμό με το TLS, είναι επομένως κρίσιμοι.

Ευαίσθητα δεδομένα στην ύπαιθρο

Κανονικά, οι ομάδες λειτουργιών και άλλες εσωτερικές ομάδες έχουν πρόσβαση σε εργαλεία ανίχνευσης για θέματα εντοπισμού σφαλμάτων, τα οποία μπορεί να παρέχουν μια σαφή εικόνα των πληροφοριών για το ωφέλιμο φορτίο API. Στην ιδανική περίπτωση, τα δεδομένα καρτών PCI (PCI) και τα προσωπικά δεδομένα υγείας (PHI) είναι κρυπτογραφημένα από το σημείο όπου τα δεδομένα συλλαμβάνονται μέχρι το σημείο όπου καταναλώνονται τα δεδομένα, αν και αυτό δεν συμβαίνει πάντοτε.

Με αυξανόμενες ανησυχίες σχετικά με την ασφάλεια API, η κρυπτογράφηση ευαίσθητων και εμπιστευτικών δεδομένων πρέπει να αποτελέσει ύψιστη προτεραιότητα. Για παράδειγμα, τον Ιούνιο του 2016 αποκαλύφθηκε μια ευπάθεια http proxy, η οποία παρείχε πολλαπλούς τρόπους για τους εισβολείς να εξουσιοδοτήσουν το εξερχόμενο αίτημα σε έναν διακομιστή επιλογής, να συλλάβουν ευαίσθητες πληροφορίες από το αίτημα και να αποκτήσουν πληροφορίες σχετικά με τα εσωτερικά δεδομένα. Πέρα από τη χρήση του TLS, είναι σημαντικό να προστατεύεται η κυκλοφορία API με κρυπτογράφηση ευαίσθητων δεδομένων, εφαρμογή αποκρύψεων δεδομένων για ανίχνευση / καταγραφή και χρήση του tokenization για πληροφορίες κάρτας.

Επανάληψη επιθέσεων

Μια σημαντική ανησυχία για τους αρχιτέκτονες επιχειρήσεων είναι η αποκαλούμενη "επανάληψη συναλλαγής". Τα API που είναι ανοιχτά στο κοινό αντιμετωπίζουν την πρόκληση να διαπιστωθεί εάν θα εμπιστευθούν τα εισερχόμενα αιτήματα. Σε πολλές περιπτώσεις, ακόμα και αν γίνει και απορριφθεί ένα μη αξιόπιστο αίτημα, το API μπορεί ευγενικά να επιτρέψει στον χρήστη - δυνητικά κακόβουλο χρήστη - να δοκιμάσει και να προσπαθήσει ξανά.

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

Τα αντίμετρα περιλαμβάνουν πολιτικές περιορισμού του ρυθμού στις αιτήσεις γκαζιού, χρήση εξελιγμένων εργαλείων όπως το Apigee Sense για την ανάλυση της κυκλοφορίας αίτησης API και ταυτοποίηση μοτίβων που αντιπροσωπεύουν ανεπιθύμητα αιτήματα bot. Πρόσθετα μέτρα ασφαλείας για επιθέσεις επανάληψης stymie περιλαμβάνουν:

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

Απροσδόκητες υπερβολές στη χρήση του API

Είναι πάντα δύσκολο να υπολογίσετε τη χρήση ενός API. Ένα καλό παράδειγμα είναι η εφαρμογή που έφερε σύντομα το API National Weather Service. Αυτό το συγκεκριμένο API δεν διέθετε κανένα μηχανισμό πρόληψης της κυκλοφοριακής ροής ή μηχανισμό στραγγαλισμού, οπότε η απροσδόκητη αύξηση της κυκλοφορίας έπληξε άμεσα το backend.

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

Κλειδιά στο URI

Για ορισμένες περιπτώσεις χρήσης, η εφαρμογή κλειδιών API για έλεγχο ταυτότητας και εξουσιοδότηση είναι αρκετά καλή. Ωστόσο, η αποστολή του κλειδιού ως μέρους του Αναγνωριστικού Ομοιόμορφου Πόρου (URI) μπορεί να οδηγήσει σε παραβίαση του κλειδιού. Όπως εξηγείται στο IETF RFC 6819, επειδή τα στοιχεία URI μπορούν να εμφανίζονται στα αρχεία καταγραφής περιήγησης ή συστήματος, ένας άλλος χρήστης μπορεί να δει τα URI από το ιστορικό του προγράμματος περιήγησης, καθιστώντας εύκολα προσβάσιμα κλειδιά API, κωδικούς πρόσβασης και ευαίσθητη ημερομηνία στα URI URI.

Είναι ασφαλέστερο να στέλνετε κλειδιά API στην κεφαλίδα εξουσιοδότησης μηνυμάτων, η οποία δεν καταγράφεται από στοιχεία δικτύου. Κατά κανόνα, συνιστάται η χρήση της μεθόδου HTTP POST με ωφέλιμο φορτίο που μεταφέρει ευαίσθητες πληροφορίες.

Στοίβα ίχνος

Πολλοί προγραμματιστές API γίνονται άνετοι χρησιμοποιώντας 200 για όλα τα αιτήματα επιτυχίας, 404 για όλες τις αποτυχίες, 500 για κάποιες εσωτερικές σφάλματα διακομιστή και, σε ορισμένες ακραίες περιπτώσεις, 200 με μήνυμα αποτυχίας στο σώμα, πάνω από ένα λεπτομερές ίχνος στοίβας. Ένα ίχνος στοίβας μπορεί ενδεχομένως να καταστεί διαρροή πληροφοριών σε κακόβουλο χρήστη όταν αποκαλύπτει υποκείμενες εφαρμογές σχεδιασμού ή αρχιτεκτονικής με τη μορφή ονομάτων πακέτων, ονομάτων τάξεων, ονομάτων πλαισίων, εκδόσεων, ονομάτων διακομιστών και ερωτημάτων SQL.

Οι επιτιθέμενοι μπορούν να εκμεταλλευτούν αυτές τις πληροφορίες υποβάλλοντας δημιουργημένα αιτήματα URL, όπως εξηγείται σε αυτό το παράδειγμα της Cisco. Είναι καλή πρακτική η επιστροφή ενός αντικειμένου "ισορροπημένου" σφάλματος, με τον σωστό κώδικα κατάστασης HTTP, με ελάχιστο απαιτούμενο μήνυμα λάθους και "κανένα ίχνος στοίβας" κατά τη διάρκεια σφαλμάτων. Αυτό θα βελτιώσει τη διαχείριση σφαλμάτων και θα προστατεύσει τις λεπτομέρειες εφαρμογής του API από έναν εισβολέα. Η πύλη API μπορεί να χρησιμοποιηθεί για τη μετατροπή των μηνυμάτων σφάλματος backend σε τυποποιημένα μηνύματα έτσι ώστε όλα τα μηνύματα λάθους να μοιάζουν παρόμοια. αυτό εξαλείφει επίσης την έκθεση της δομής κώδικα backend.

Διατηρήστε ασφαλή API

Όπως αναλύσαμε σε αυτό το άρθρο, πολλές πιθανές απειλές μπορούν να αποφευχθούν κάνοντας κάποια σκέψη στο σχεδιασμό API και στη θέσπιση πολιτικών διακυβέρνησης που μπορούν να εφαρμοστούν σε όλη την επιχείρηση. Είναι σημαντικό να προστατεύετε τα API από το περιεχόμενο κακόβουλων μηνυμάτων, προσφέροντας και καλύπτοντας ευαίσθητα κρυπτογραφημένα δεδομένα κατά το χρόνο εκτέλεσης και προστατεύοντας τις υπηρεσίες backend από την άμεση πρόσβαση. Ένα σφάλμα ασφαλείας API μπορεί να έχει σημαντικές συνέπειες - αλλά με τη σωστή προοπτική και διαχείριση, οι επιχειρήσεις μπορούν να γίνουν πολύ πιο ασφαλείς.

[Ψάχνετε να μάθετε περισσότερα για την ασφάλεια API; Αποκτήστε το αντίγραφο του πρόσφατου ηλεκτρονικού μας βιβλίου, Μέσα στο μυαλό προϊόντος API: Δημιουργία και διαχείριση ασφαλών API.]