Μετάβαση στο περιεχόμενο

API5:2019 Broken Function Level Authorization

Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) Αδυναμία Ασφαλείας (Security Weakness) Επιπτώσεις (Impacts)
Εξαρτώνται από το API : Εκμεταλλευσιμότητα 3 Επικράτηση (Prevalence) 2 : Ανιχνευσιμότητα 1 Τεχνικές Επιπτώσεις 2 : Εξαρτώνται από την Επιχείρηση
Η εκμετάλλευση (exploitation) αυτής της αδυναμίας ασφαλείας απαιτεί από τον εισβολέα (attacker) να στείλει έγκυρες κλήσεις σε τελικό σημείο προορισμού API (endpoint) στο οποίο κανονικά δεν θα πρέπει να έχει πρόσβαση. Αυτά τα τελικά σημεία προορισμού ενδέχεται να εκτίθενται σε ανώνυμους χρήστες ή/και σε κανονικούς, μη προνομιούχους/εξουσιοδοτημένους χρήστες (non-privileged users). Είναι εύκολο να ανακαλύψετε τέτοιου είδους ελαττώματα σε APIs καθώς τα APIs έχουν δομή και ο τρόπος πρόσβασης σε ορισμένες λειτουργίες είναι εύκολα προβλέψιμος (π.χ. αντικατάσταση της μεθόδου HTTP από GET σε PUT ή αλλαγή της συμβολοσειράς "users" στη διεύθυνση URL σε "admins" ). Οι έλεγχοι εξουσιοδότησης (authorization checks) για μια λειτουργία (function) ή έναν πόρο συστήματος (resource) βασίζονται συνήθως σε ρυθμίσεις (configuration) και μερικές φορές υλοποιούνται σε επίπεδο κώδικα. Η εφαρμογή των κατάλληλων και σωστών ελέγχων εξουσιοδότησης είναι συνήθως μια περίπλοκη εργασία, καθώς οι σύγχρονες εφαρμογές ενδέχεται να περιέχουν πολλούς τύπους ρόλων ή ομάδων και πολύπλοκη ιεραρχία χρηστών (π.χ. υπο-χρήστες, χρήστες με περισσότερους από έναν ρόλους). Οι αδυναμίες ασφαλείας αυτές επιτρέπουν στους εισβολείς να έχουν πρόσβαση σε μη εξουσιοδοτημένες λειτουργίες. Οι διαχειριστικές λειτουργίες (administrative functions) είναι οι βασικοί στόχοι για αυτό το είδος επίθεσης.

Πότε το API είναι ευάλωτο

Ο καλύτερος τρόπος για να βρείτε αδυναμίες ασφαλείας εξουσιοδότησης σε επίπεδο λειτουργιών (Broken Function Level Authorization) είναι να πραγματοποιήσετε μια ενδελεχή ανάλυση (deep analysis) του μηχανισμού εξουσιοδότησης (authorization mechanism). Λάβετε υπόψιν σας την ιεραρχία των χρηστών, τους διαφορετικούς ρόλους ή/και τις ομάδες του συστήματος χρησιμοποιώντας τις ακόλουθες ερωτήσεις:

  • Μπορεί ένας κανονικός χρήστης να έχει πρόσβαση στα τελικά σημεία διαχείρισης (administrative endpoints);
  • Μπορεί ένας χρήστης να εκτελέσει ευαίσθητες ενέργειες (π.χ. δημιουργία, τροποποίηση ή διαγραφή) στις οποίες δεν θα έπρεπε να έχει πρόσβαση αλλάζοντας απλώς τη μέθοδο HTTP (π.χ. από "GET" σε "DELETE");
  • Μπορεί ένας χρήστης από την ομάδα Χ να αποκτήσει πρόσβαση σε μια λειτουργία που θα πρέπει να εκτίθεται μόνο σε χρήστες από την ομάδα Υ, μαντεύοντας απλώς τη διεύθυνση URL του τελικού σημείου προορισμού και τις παραμέτρους (π.χ. /api/v1/users/export_all);

Μην υποθέτετε ότι ένα τελικό σημείο API είναι κανονικό ή διαχειριστικό μόνο με βάση τη διαδρομή URL.

Παρόλο που οι προγραμματιστές ενδέχεται να επιλέξουν να εκθέσουν τα περισσότερα από τα διαχειριστικά τελικά σημεία προορισμού σε μια συγκεκριμένη σχετική διαδρομή, όπως api/admins, είναι πολύ συνηθισμένο να βρίσκουμε αυτά τα τελικά σημεία διαχείρισης και σε άλλες σχετικές διαδρομές μαζί με κανονικά τελικά σημεία προορισμού, όπως api/users.

Παραδείγματα Σεναρίων Επίθεσης

Σενάριο Επίθεσης #1

Κατά τη διαδικασία εγγραφής σε μια εφαρμογή που επιτρέπει τη συμμετοχή μόνο σε προσκεκλημένους χρήστες, η εφαρμογή για κινητά εκτελεί μια κλήση API στο GET /api/invites/{invite_guid}. Η απάντηση περιέχει ένα JSON με λεπτομέρειες σχετικές με την πρόσκληση, συμπεριλαμβανομένου του ρόλου του χρήστη και του email του χρήστη.

Ένας εισβολέας αντέγραψε το αίτημα και άλλαξε τη μέθοδο HTTP και το τελικό σημείο σε POST /api/invites/new. Αυτό το τελικό σημείο προορισμού θα πρέπει να είναι προσβάσιμο μόνο από διαχειριστές που χρησιμοποιούν την κονσόλα διαχείρισης, το οποίο όμως τελικό σημείο προορισμού δεν εφαρμόζει ελέγχους εξουσιοδότησης σε επίπεδο λειτουργίας.

Ο εισβολέας εκμεταλλεύεται το πρόβλημα και στέλνει στον εαυτό του μια πρόσκληση για να δημιουργήσει έναν λογαριασμό διαχειριστή:

POST /api/invites/new

{“email”:”[email protected]”,”role”:”admin”}

Σενάριο Επίθεσης #2

Ένα API περιέχει ένα τελικό σημείο προορισμού (endpoint) που θα πρέπει να είναι προσβάσιμο μόνο στους διαχειριστές - GET /api/admin/v1/users/all. Αυτό το τελικό σημείο προορισμού επιστρέφει τα στοιχεία όλων των χρηστών της εφαρμογής και δεν εφαρμόζει ελέγχους εξουσιοδότησης σε επίπεδο λειτουργίας. Ένας εισβολέας που έμαθε τη δομή του API κάνει μια πιθανή εικασία και καταφέρνει να αποκτήσει πρόσβαση σε αυτό το τελικό σημείο προορισμού, το οποίο εκθέτει ευαίσθητες λεπτομέρειες των χρηστών της εφαρμογής.

Τρόπος Πρόληψης

Η εφαρμογή σας θα πρέπει να διαθέτει ένα σταθερό και εύκολο στην ανάλυση υποσύστημα εξουσιοδότησης (authorization module) το οποίο θα χρησιμοποιείται από όλες τις επιχειρησιακές λειτουργίες (business functions).

Συχνά, μια τέτοια προστασία παρέχεται από ένα ή περισσότερα υποσυστήματα (components) που βρίσκονται εκτός του κώδικα της εφαρμογής.

  • Οι μηχανισμοί επιβολής θα πρέπει από προεπιλογή (by default) να απαγορεύουν κάθε πρόσβαση, απαιτώντας ρητές εξουσιοδοτήσεις (explicit grants) σε συγκεκριμένους ρόλους για πρόσβαση σε κάθε λειτουργία.
  • Ελέγξτε τα τελικά σημεία προορισμού του API σας σε σχέση με τις αδυναμίες ασφαλείας εξουσιοδότησης σε επίπεδο λειτουργίας (function level), λαμβάνοντας παράλληλα υπόψη την επιχειρησιακή λογική (business logic) της εφαρμογής και της ιεραρχίας των ομάδων χρηστών.
  • Βεβαιωθείτε ότι όλα τα διαχειριστικά υποσυστήματα (controllers) βασίζουν την λειτουργία τους σε ένα γενικό διαχειριστικό υποσύστημα (abstract controller) που εφαρμόζει ελέγχους εξουσιοδότησης βάσει της ομάδας και του ρόλου του χρήστη.
  • Βεβαιωθείτε ότι οι λειτουργίες διαχείρισης μέσα σε ένα κανονικό διαχειριστικό υποσύστημα (controller) εφαρμόζουν ελέγχους εξουσιοδότησης βάσει της ομάδας και του ρόλου του χρήστη.

Αναφορές (References)

Αναφορές OWASP

Εξωτερικές Αναφορές