API2:2019 Broken User Authentication
| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) |
|---|---|---|
| Εξαρτώνται από το API : Εκμεταλλευσιμότητα 3 | Επικράτηση (Prevalence) 2 : Ανιχνευσιμότητα 2 | Τεχνικές Επιπτώσεις 3 : Εξαρτώνται από την Επιχείρηση |
| Ο έλεγχος ταυτότητας στα APIs είναι ένας πολύπλοκος και μπερδεμένος μηχανισμός. Οι μηχανικοί λογισμικού και ασφαλείας ενδέχεται να έχουν λανθασμένες αντιλήψεις σχετικά με τα όρια του ελέγχου ταυτότητας και πώς να τον εφαρμόσουν σωστά. Επιπλέον, ο μηχανισμός ελέγχου ταυτότητας είναι ένας εύκολος στόχος για τους εισβολείς, καθώς είναι προσβάσιμος σε όλους. Αυτοί οι δύο λόγοι καθιστούν τον μηχανισμό ελέγχου ταυτότητας δυνητικά ευάλωτο σε πολλές επιθέσεις (exploits). | Υπάρχουν δύο υποκατηγορίες του κενού ασφαλείας: 1. Έλλειψη μηχανισμών προστασίας: Τα τελικά σημεία προορισμού APIs που είναι υπεύθυνα για τον έλεγχο ταυτότητας πρέπει να αντιμετωπίζονται διαφορετικά από τα κανονικά τελικά σημεία προορισμού και να εφαρμόζουν επιπλέον επίπεδα προστασίας. 2. Εσφαλμένη εφαρμογή του μηχανισμού: Ο μηχανισμός χρησιμοποιείται / υλοποιείται χωρίς να λαμβάνονται υπόψη τα διανύσματα επίθεσης (attack vectors) ή είναι λάθος η περίπτωση χρήσης του (π.χ. ένας μηχανισμός ελέγχου ταυτότητας που έχει σχεδιαστεί για εφαρμογές-πελάτες (clients) IoT μπορεί να μην είναι η σωστή επιλογή για εφαρμογές Ιστού). | Οι εισβολείς μπορούν να αποκτήσουν τον έλεγχο λογαριασμών άλλων χρηστών στο σύστημα, να διαβάσουν τα προσωπικά τους δεδομένα και να εκτελέσουν ευαίσθητες / διαβαθμισμένες ενέργειες για λογαριασμό τους, όπως συναλλαγές χρημάτων και αποστολή προσωπικών μηνυμάτων. |
Πότε το API είναι ευάλωτο
Τα τελικά σημεία προορισμού (endpoints) και οι ροές (flows) ελέγχου ταυτότητας είναι στοιχεία που πρέπει να προστατεύονται. Λειτουργίες όπως το "Ξέχασα τον κωδικό πρόσβασης / επαναφορά κωδικού πρόσβασης" θα πρέπει να αντιμετωπίζονται με τον ίδιο τρόπο όπως και οι μηχανισμοί ελέγχου ταυτότητας.
Ένα API είναι ευάλωτο εάν:
* Επιτρέπει credential stuffing με το οποίο ο εισβολέας έχει την δυνατότητα να αυτοματοποιήσει την προσπάθεια πρόσβασης χρησιμοποιώντας κλεμμένες λίστες με έγκυρα ονόματα χρηστών και κωδικών πρόσβασης.
* Επιτρέπει στους εισβολείς να εκτελούν επίθεση ωμής βίας (brute force attack) στον ίδιο λογαριασμό χρήστη, χωρίς να παρουσιάζουν μηχανισμό captcha ή κλειδώματος λογαριασμού.
* Επιτρέπει αδύναμους κωδικούς πρόσβασης.
* Στέλνει ευαίσθητες λεπτομέρειες ελέγχου ταυτότητας, όπως διακριτικά ταυτότητας (authentication tokens) και κωδικούς πρόσβασης στη διεύθυνση URL (δηλαδή μέσω χρήσης GET HTTP requests).
* Δεν επικυρώνει την αυθεντικότητα των διακριτικών.
* Αποδέχεται ανυπόγραφα/ασθενώς υπογεγραμμένα διακριτικά JWT ("alg":"none")/δεν επικυρώνει την ημερομηνία λήξης τους.
* Διαχειρίζεται κωδικούς πρόσβασης ως απλό κείμενο, χωρίς την χρήση κρυπτογράφησης ή χρησιμοποιεί αδύναμους αλγόριθμους κρυπτογράφησης ή κατακερματισμού (hashing).
* Χρησιμοποιεί αδύναμα κλειδιά κρυπτογράφησης.
Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Το Credential stuffing (χρησιμοποιώντας λίστες γνωστών ονομάτων χρήστη/κωδικών πρόσβασης), είναι μια συνηθισμένη επίθεση. Εάν μια εφαρμογή δεν εφαρμόζει προστασία από αυτοματοποιημένες απειλές ή credential stuffing, η εφαρμογή μπορεί να χρησιμοποιηθεί από τους εισβολείς ως ένα μέσο για να προσδιορίσουν εάν τα διαπιστευτήρια είναι έγκυρα. Η τεχνική αυτή μετατρέπει το API σε έναν ελεγκτή (ή μαντείο - oracle) κωδικών πρόσβασης.
Σενάριο Επίθεσης #2
Ένας εισβολέας ξεκινάει τη διαδικασία ανάκτησης κωδικού πρόσβασης στέλνοντας ένα
αίτημα HTTP POST στο /api/system/verification-codes και παρέχοντας το όνομα χρήστη
στο σώμα του αιτήματος (request). Στη συνέχεια, αποστέλλεται μέσω SMS ένας κωδικός με 6 ψηφία στο τηλέφωνο του θύματος. Επειδή το API δεν διαθέτει προστασία περιορισμού του ρυθμού των αιτημάτων, ο εισβολέας μπορεί να δοκιμάσει όλους τους πιθανούς συνδυασμούς χρησιμοποιώντας μία πολυνηματική εφαρμογή (multi-threaded script) η οποία στέλνει πολλαπλά αιτήματα στο σημείο προορισμού (URL endpoint) /api/system/verification-codes/{smsToken} έως ότου ανακαλύψει τον σωστό 6-ψήφιο κωδικό. Ένα τέτοιο σενάριο επίθεσης μπορεί να ολοκληρωθεί μέσα σε λίγα λεπτά.
Τρόπος Πρόληψης
- Βεβαιωθείτε ότι γνωρίζετε όλες τις πιθανές ροές εκτέλεσης (execution flows) για έλεγχο ταυτότητας στο API (σύνδεσμοι για κινητά/ιστό/deep links που εφαρμόζουν έλεγχο ταυτότητας με ένα κλικ/κ.λπ.)
- Επιβεβαιώστε με τους μηχανικούς σας όλες τις ροές εκτέλεσης.
- Διαβάστε σχετικά με τους μηχανισμούς ελέγχου ταυτότητας. Βεβαιωθείτε ότι καταλαβαίνετε τι και πώς χρησιμοποιούνται. Το OAuth δεν είναι έλεγχος ταυτότητας, ούτε και τα κλειδιά API.
- Μην ανακαλύπτετε ξανά τον τροχό στον έλεγχο ταυτότητας, τη δημιουργία διακριτικών, τους τρόπους αποθήκευσης κωδικών πρόσβασης. Χρησιμοποιήστε τις καθιερωμένες προδιαγραφές (standards).
- Τα τελικά σημεία ανάκτησης διαπιστευτηρίων/λήψης κωδικού πρόσβασης θα πρέπει να αντιμετωπίζονται ως τελικά σημεία σύνδεσης. Εφαρμόστε τα ίδια συστήματα ασφαλείας κατά επιθέσεων όπως την ωμή βία (brute force), τον περιορισμό του ρυθμού (rate limiting) και τις προστασίες κλειδώματος.
- Συμβουλευτείτε και χρησιμοποιήστε το OWASP Authentication Cheatsheet.
- Όπου είναι δυνατόν, εφαρμόστε έλεγχο ταυτότητας πολλαπλών παραγόντων (multi-factor authentication).
- Εφαρμόστε μηχανισμούς κατά της ωμής βίας για τον μετριασμό του credential stuffing, της επίθεσης λεξικού και των επιθέσεων ωμής βίας στα τελικά σημεία ελέγχου ταυτότητας. Αυτός ο μηχανισμός θα πρέπει να είναι πιο αυστηρός από τον κανονικό μηχανισμό περιορισμού ρυθμών στο API σας.
- Εφαρμόστε το μηχανισμό account lockout / captcha για να αποτρέψετε την ωμή βία εναντίον συγκεκριμένων χρηστών. Εφαρμόστε ελέγχους αδύναμου κωδικού πρόσβασης.
- Τα κλειδιά API δεν πρέπει να χρησιμοποιούνται για έλεγχο ταυτότητας χρήστη, αλλά για client app/project authentication.