Τα 10 Κορυφαία Ρίσκα Ασφαλείας API

TOCΠίνακας Περιεχομένων

Πίνακας Περιεχομένων

Σχετικά με το OWASPTOC Πίνακας Περιεχομένων.....................................2
FW Πρόλογος.............................................................3
I Εισαγωγή..................................................................4
RN Σημειώσεις Έκδοσης............................................5
RISK Ρίσκα Ασφαλείας API......................................6T10 Τα 10 Κορυφαία Ρίσκα Ασφαλείας API - 2019. .7
API1:2019 Broken Object Level Authorization.........8
API2:2019 Broken User Authentication...................10
API3:2019 Excessive Data Exposure.......................12
API4:2019 Lack of Resources & Rate Limiting......14
API5:2019 Broken Function Level Authorization. . .16
API6:2019 Mass Assignment...................................18
API7:2019 Security Misconfiguration.....................20
API8:2019 Injection.................................................22
API9:2019 Improper Assets Management................24
API10:2019 Insufficient Logging & Monitoring.....26+D Επόμενα Βήματα για Προγραμματιστές............28+DSO Επόμενα Βήματα για DevSecOps.................29+DAT Μεθοδολογία και Δεδομένα..........................30+ACK Ευχαριστίες...................................................31

Το OWASP (Open Web Application Security Project) είναι
μια ανοιχτή κοινότητα που αποσκοπεί στο να βοηθήσει
οργανισμούς να παράγουν, να προμηθεύονται και νασυντηρούν εφαρμογές και API που θα είναι ασφαλή.
Στο OWASP θα βρείτε δωρεάν διαθέσιμα τα παρακάτω:•Εργαλεία ασφαλείας εφαρμογών καθώς καιπρότυπα ασφαλείας (standards).
• Ολόκληρα βιβλία για testing ασφαλείας
εφαρμογών, ανάπτυξη ασφαλούς κώδικα, καιελέγχου (review) ασφαλούς κώδικα.
• Παρουσιάσεις και βίντεο.
• Σκονάκια (cheatsheets) σε πολλά συνήθη θέματα.
• Standard ελέγχους ασφαλείας και βιβλιοθήκες.
• Τοπικά chapters σε όλο τον κόσμο.
• Κορυφαίες έρευνες.
• Συνέδρια σε όλο τον κόσμο.
• Λίστες ταχυδρομείου.
Μάθετε περισσότερα στο: https://www.owasp.org.
Όλα τα εργαλεία, έγγραφα, βίντεο, παρουσιάσεις καιπαραρτήματα (chapters) του OWASP είναι δωρεάν
διαθέσιμα και ελεύθερα προσβάσιμα σε όλους όσους
ενδιαφέρονται να βελτιώσουν την ασφάλεια τωνεφαρμογών τους.
Προσεγγίζουμε την ασφάλεια εφαρμογών ως έναπρόβλημα ανθρώπων, διεργασιών και τεχνολογίας, καθώς
οι πιο αποτελεσματικές προσεγγίσεις στο πρόβλημα
απαιτούν βελτιώσεις στους παραπάνω τομείς.
Το OWASP είναι ένα νέο είδος οργανισμού. Ηανεξαρτησία μας από τυχόν εμπορικές πιέσεις μαςεπιτρέπει να παρέχουμε αμερόληπτες, πρακτικές καιοικονομικά αποδοτικές πληροφορίες σχετικά με τηνασφάλεια εφαρμογών.
Το OWASP δεν είναι συνδεδεμένο με καμία εταιρεία
τεχνολογίας. Παρόλα αυτά υποστηρίζουμε την σωστή
χρήση της εμπορικής τεχνολογίας ασφαλείας. Το OWASPπαράγει υλικό με συλλογικό, διαφανή και ανοιχτό τρόπο.
Το Ίδρυμα OWASP είναι η μη κερδοσκοπική οντότητα πουδιασφαλίζει την μακροπρόθεσμη επιτυχία αυτού τουέργου. Σχεδόν όλοι όσοι σχετίζονται με το OWASP είναι
εθελοντές, συμπεριλαμβανομένου του διοικητικού
συμβουλίου OWASP, των επικεφαλής των παραρτημάτων
(chapters), των επικεφαλής έργων και των μελών τωνέργων (projects). Υποστηρίζουμε την καινοτόμο έρευναστον τομέα ασφαλείας με επιχορηγήσεις και υποδομές.
Σας καλούμε να συμμετάσχετε και εσείς στο OWASP!

https://owasp.org

H παρούσα εργασία διατίθεται υπό την άδειαCreative Commons Attribution ShareAlike 4.0 International LicenseFWΠρόλογοςΈνα θεμελιώδες στοιχείο καινοτομίας στον σημερινό κόσμο που βασίζεται στις εφαρμογές είναι η διεπαφή
προγραμματισμού εφαρμογών (API). Από τις τράπεζες, το λιανικό εμπόριο και τις μεταφορές έως το IoT, τααυτόνομα οχήματα και τις έξυπνες πόλεις, τα API αποτελούν κρίσιμο μέρος των σύγχρονων εφαρμογών γιακινητά, SaaS και web. Τα API μπορούν να βρεθούν σε εφαρμογές που απευθύνονται σε πελάτες, σε εφαρμογές
που απευθύνονται σε συνεργάτες και σε ενδοεταιρικές εφαρμογές.
Από τη φύση τους, τα APIs αφήνουν εκτεθειμένες ορισμένες πτυχές της επιχειρηματικής λογικής τηςεφαρμογής (business logic) καθώς και ευαίσθητα δεδομένα όπως οι Προσωπικές Αναγνωριστικές Πληροφορίες
(PII) (Σ.τ.Μ. πληροφορίες που επιτρέπουν την αναγνώριση προσώπου). Γι' αυτό τον λόγο τα API γίνονται όλοκαι περισσότερο στόχος κακόβουλων χρηστών. Χωρίς ασφαλή APIs, η ταχεία καινοτομία θα ήταν αδύνατη.
Παρόλο που ένα γενικευμένο Top 10 με κινδύνους ασφαλείας για web εφαρμογές εξακολουθεί να έχει νόημα,λόγω της ιδιαίτερης φύσης των APIs, απαιτείται μια λίστα ρίσκων ασφαλείας ειδικά για τα API. Η ασφάλεια
των APIs εστιάζει σε στρατηγικές και λύσεις για την κατανόηση και την αντιμετώπιση των μοναδικών τρωτών
σημείων και ρίσκων ασφαλείας που σχετίζονται με τα APIs.
Εάν είστε εξοικειωμένοι με το OWASP Top 10 Project, τότε θα παρατηρήσετε τις ομοιότητες μεταξύ των δύοκαταγραφών: στόχος τους είναι η εύκολη ανάγνωση (readability) και εύκολη υιοθέτηση (adoption). Εάν είστε
νέος στη σειρά OWASP Top 10 ίσως είναι καλύτερα να διαβάσετε τις ενότητες Ρίσκα Ασφαλείας API καιΜεθοδολογία και Δεδομένα πριν μεταβείτε στη λίστα Top 10.
Μπορείτε να συνεισφέρετε στο OWASP API Security Top 10 με τις ερωτήσεις, τα σχόλια και τις ιδέες σας στοηλεκτρονικό «αποθετήριο» (repository) του έργου στο GitHub:• https://github.com/OWASP/API-Security/issues• https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md
Μπορείτε να βρείτε το OWASP API Security Top 10 εδώ:• https://www.owasp.org/index.php/OWASP_API_Security_Project• https://github.com/OWASP/API-SecurityΘέλουμε να ευχαριστήσουμε όλους τους συντελεστές που κατέστησαν δυνατό αυτό το έργο με την προσπάθεια
και τη συνεισφορά τους. Όλοι τους αναφέρονται στην ενότητα Ευχαριστίες. Σας ευχαριστούμε!

IΕισαγωγή

Καλώς ήρθατε στο OWASP API Security Top 10 - 2019!
Καλώς ήρθατε στην πρώτη έκδοση του OWASP API Security Top 10. Εάν είστε εξοικειωμένοι με τη σειράOWASP Top 10 τότε θα παρατηρήσετε τις ομοιότητες μεταξύ των δύο καταγραφών: στόχος τους είναι ηεύκολη ανάγνωση (readability) και η εύκολη υιοθέτηση (adoption). Σε διαφορετική περίπτωση, εξετάστε τοενδεχόμενο να επισκεφτείτε τη σελίδα OWASP API Security Project wiki page, προτού εμβαθύνετε στους πιοκρίσιμους κινδύνους για την ασφάλεια των APIs.
Τα APIs παίζουν πολύ σημαντικό ρόλο στην αρχιτεκτονική των σύγχρονων εφαρμογών. Εφόσον η δράση
ευαισθητοποίησης του κοινού για την ασφάλεια και η καινοτομία έχουν διαφορετικούς ρυθμούς, είναι
σημαντικό να εστιάσετε στις συνηθισμένες αδυναμίες ασφαλείας APIs.
Ο πρωταρχικός στόχος του OWASP API Security Top 10 είναι να εκπαιδεύσει όσους εμπλέκονται στηνανάπτυξη και συντήρηση APIs, για παράδειγμα, προγραμματιστές, σχεδιαστές, αρχιτέκτονες, διαχειριστές ήεπιχειρήσεις / οργανισμούς.
Στην ενότητα Μεθοδολογία και Δεδομένα, μπορείτε να διαβάσετε περισσότερα για το πώς δημιουργήθηκε
αυτή η πρώτη έκδοση. Σε μελλοντικές εκδόσεις, θέλουμε να συνεργαστούμε με τις επιχειρήσεις του τομέα της
ασφαλείας εφαρμογών (security industry), με μια δημόσια πρόσκληση για διαμοιρασμό δεδομένων. Προς τοπαρόν, ενθαρρύνουμε όλους να συνεισφέρουν με ερωτήσεις, σχόλια και ιδέες στο αποθετήριο (repository)
GitHub ή στη Λίστα αλληλογραφίας.

RN

Σημειώσεις Έκδοσης

Αυτή είναι η πρώτη έκδοση του OWASP API Security Top 10. Σκοπός μας είναι η έκδοση να ενημερώνεται
περιοδικά κάθε τρία ή τέσσερα χρόνια.
Σε μελλοντικές εκδόσεις, σε αντίθεση με την παρούσα έκδοση, θέλουμε να κάνουμε μια δημόσια πρόσκλησηγια δεδομένα, σε συνεργασία με τις επιχειρήσεις του τομέα της ασφάλειας εφαρμογών (security industry) σεαυτή την προσπάθεια. Στην ενότητα Μεθοδολογία και Δεδομένα θα βρείτε περισσότερες πληροφορίες σχετικά
με τον τρόπο δημιουργίας αυτής της έκδοσης. Για περισσότερες λεπτομέρειες σχετικά με τους κινδύνους
ασφαλείας, ανατρέξτε στην ενότητα Ρίσκα Ασφαλείας API.
Είναι σημαντικό να συνειδητοποιήσουμε ότι τα τελευταία χρόνια, η αρχιτεκτονική των εφαρμογών έχειαλλάξει σημαντικά. Επί του παρόντος, τα APIs διαδραματίζουν πολύ σημαντικό ρόλο σε αυτή τη νέααρχιτεκτονική των μικροϋπηρεσιών (microservices), των εφαρμογών μιας σελίδας (SPA), των εφαρμογών γιακινητά, του IoT κ.λπ.
Το OWASP API Security Top 10 ήταν μια απαραίτητη προσπάθεια για την ευαισθητοποίηση του κοινού
σχετικά με τα σύγχρονα ζητήματα ασφαλείας των APIs. Αυτό ήταν εφικτό μόνο χάρη στη σημαντική
προσπάθεια πολλών εθελοντών οι οποίοι αναφέρονται στην ενότητα Ευχαριστίες. Σας ευχαριστούμε!

Σημειώσεις Μετάφρασης
Η μετάφραση του OWASP API Security Top 10 2019 πραγματοποιήθηκε εθελοντικά με στόχο να γίνει ηκαταγραφή προσβάσιμη και στην ελληνική γλώσσα.
Πιστεύουμε ότι αυτή είναι μια ουσιαστική συνεισφορά στην αποστολή της ευαισθητοποίησης και τηςεκπαίδευσης όλων όσων εμπλέκονται στην ανάπτυξη και συντήρηση APIs και λογισμικού γενικότερα γιαθέματα που σχετίζονται με την ασφάλεια.
Η ελληνική μετάφραση προέκυψε από την προσπάθεια των παρακάτω:••Athanasios Emmanouilidis https://www.linkedin.com/in/athanasiosem/
Apostolos Giannakidis https://www.linkedin.com/in/giannakidisapostolos/

RISKΡίσκα Ασφαλείας APIΓια την ανάλυση κινδύνου χρησιμοποιήθηκε η Mεθοδολογία Αξιολόγησης Ρίσκου OWASP.
Ο παρακάτω πίνακας συνοψίζει την ορολογία που σχετίζεται με τη βαθμολογία κινδύνου.
Επικράτηση
Αδυναμίας
(Weakness
Prevalence)Ανιχνευσιμότητ
α Αδυναμίας
(Weakness
Detectability)Τεχνικός
Αντίκτυπος
(TechnicalImpact)Εύκολη: 3Διαδεδομένη 3Εύκολη 3Σοβαρός 3Μεσαία: 2Κοινή 2Μεσαία 2Μεσαίος 2Δύσκολη: 1Δύσκολη 1Δύσκολη 1Μικρός 1Παράγοντες
ΕκμεταλλευσιμΑπειλής
ότητα
(Threat Agents) (Exploitability)Εξαρτώνται απότο APIΕπιχειρησιακές
Επιπτώσεις
(Business
Impacts)Εξαρτώνται απότην επιχείρηση

Σημείωση: Η παραπάνω προσέγγιση δεν λαμβάνει υπόψη την πιθανότητα του παράγοντα απειλής (likelihoodof threat agent). Επίσης δεν λαμβάνει υπόψη καμία από τις διάφορες τεχνικές λεπτομέρειες που σχετίζονται μετη συγκεκριμένη εφαρμογή σας. Οποιοσδήποτε από αυτούς τους παράγοντες θα μπορούσε να επηρεάσει
σημαντικά τη συνολική πιθανότητα ο εισβολέας να βρει και να εκμεταλλευτεί μια συγκεκριμένη ευπάθεια.
Αυτή η βαθμολογία δεν λαμβάνει υπόψη τον πραγματικό αντίκτυπο στην επιχείρησή σας. Ηεπιχείρηση/οργανισμός σας θα πρέπει να αποφασίσει πόσο ρίσκο ασφαλείας από τις εφαρμογές και τα APIsείναι διατεθειμένος να αποδεχτεί, δεδομένης της εταιρικής κουλτούρας/πολιτικών, του κλάδου και τουρυθμιστικού περιβάλλοντος. Ο σκοπός του OWASP API Security Top 10 δεν είναι να κάνει αυτήν την ανάλυση
κινδύνου για εσάς.

Αναφορές (References)Αναφορές OWASP•OWASP Risk Rating Methodology•

Article on Threat/Risk ModelingΕξωτερικές Αναφορές
•
•
•
•
•
•

ISO 31000: Risk Management Std
ISO 27001: ISMSNIST Cyber Framework (US)ASD Strategic Mitigations (AU)NIST CVSS 3.0
Microsoft Threat Modeling ToolT10

OWASP API Security Top 10 - 2019

API1:2019 - Broken Object Level AuthorizationΠολύ συχνά, τα APIs εκθέτουν τελικά σημεία προορισμού (endpoints) πουχειρίζονται αναγνωριστικά αντικειμένων (object IDs), δημιουργώντας μία ευρεία
επιφάνεια έκθεσης σε πιθανές επιθέσεις επιπέδου ελέγχου πρόσβασης (wide attack
surface Level Access Control). Οι έλεγχοι εξουσιοδότησης σε επίπεδο αντικειμένου
(Object Level Authorization) θα πρέπει να λαμβάνονται υπόψη σε κάθε λειτουργίαπου έχει πρόσβαση σε δεδομένα προερχόμενα από χρήστες.

API2:2019 - Broken User AuthenticationΟι μηχανισμοί ελέγχου ταυτότητας χρηστών συχνά υλοποιούνται εσφαλμένα,επιτρέποντας στους εισβολείς να διακυβεύουν τα διακριτικά ελέγχου ταυτότητας ήνα εκμεταλλεύονται ελαττώματα στην υλοποίηση της εφαρμογής για ναπροσποιούνται προσωρινά ή μόνιμα τις ταυτότητες άλλων χρηστών. Ότανδιακυβεύεται η ικανότητα του συστήματος να αναγνωρίζει τον χρήστη / εφαρμογήπελάτη (client) τότε θέτεται σε κίνδυνο η ασφάλεια των APIs συνολικά.

API3:2019 - Excessive Data ExposureΣτοχεύοντας σε γενικευμένες υλοποιήσεις (generic implementations), οιπρογραμματιστές τείνουν να εκθέτουν όλα τα δεδομένα/ιδιότητες των αντικειμένων
(object properties) χωρίς να λαμβάνουν υπόψη την ατομική τουςευαισθησία/εμπιστευτικότητα, βασιζόμενοι ότι οι εφαρμογές-πελάτες θα εκτελέσουντο φιλτράρισμα δεδομένων πριν τα εμφανίσουν στον χρήστη.

API4:2019 - Lack of Resources & Rate LimitingΠολύ συχνά, τα APIs δεν επιβάλλουν περιορισμούς στο μέγεθος ή τον αριθμό τωνπόρων που μπορεί να ζητήσει ο χρήστης / εφαρμογή-πελάτη (client). Αυτό όχι μόνομπορεί να επηρεάσει την απόδοση του διακομιστή API, οδηγώντας σε άρνησηυπηρεσίας (DoS), αλλά αφήνει επίσης ανοιχτό το ενδεχόμενο ελαττωμάτων ελέγχου
ταυτότητας, όπως η ωμή βία (brute force).

API5:2019 - Broken Function Level
AuthorizationΠολύπλοκες πολιτικές ελέγχου πρόσβασης με διαφορετικές ιεραρχίες, ομάδες καιρόλους, καθώς και ασαφείς διαχωρισμοί μεταξύ διαχειριστικών/διαβαθμισμένων
(administrative) και μη-διαβαθμισμένων λειτουργιών, τείνουν να οδηγούν σεελαττώματα εξουσιοδότησης. Εκμεταλλευόμενοι αυτά τα ζητήματα, οι εισβολείς
αποκτούν πρόσβαση σε πόρους ή/και διαβαθμισμένες λειτουργίες άλλων χρηστών.

API6:2019 - Mass AssignmentΗ σύνδεση δεδομένων που προέρχονται από χρήστες ή εφαρμογές-πελάτες (π.χ.
JSON) σε μοντέλα δεδομένων, χωρίς το κατάλληλο φιλτράρισμα ιδιοτήτων βάσει
μιας λίστας επιτρεπόμενων δεδομένων (whitelist), συνήθως οδηγεί σε μαζική
εκχώρηση δεδομένων (Mass Assignment). Οι εισβολείς καταφέρνουν νατροποποιήσουν τις ιδιότητες αντικειμένων που δεν θα έπρεπε να έχουν πρόσβαση νατροποποιήσουν με διάφορους τρόπους, όπως με το να μαντεύουν τις ιδιότητες τωναντικειμένων, την εξερεύνηση άλλων τελικών σημείων προορισμού (API endpoints),την μελέτη της τεκμηρίωσης του λογισμικού (documentation) ή την παροχή
πρόσθετων ιδιοτήτων αντικειμένων σε ωφέλιμα φορτία αιτημάτων (request
payloads).

API7:2019 - Security MisconfigurationΟι εσφαλμένες ρυθμίσεις ασφαλείας είναι συνήθως αποτέλεσμα μη ασφαλών
προεπιλεγμένων ρυθμίσεων, ελλιπών ή αυτοσχέδιων/πρόχειρων (ad-hoc) ρυθμίσεων,χώρου αποθήκευσης cloud με ελλιπείς ή χωρίς περιορισμούς χρήσης, εσφαλμένων
ρυθμίσεων κεφαλίδων HTTP (headers), περιττών μεθόδων HTTP, επιτρεπόμενηςκοινής χρήσης πόρων Cross-Origin (CORS) και λεπτομερών μηνυμάτων σφάλματοςπου περιέχουν ευαίσθητες πληροφορίες.

API8:2019 - InjectionΣφάλματα Έγχυσης (Injection Flaws), όπως SQL, NoSQL, Command Injection κ.λπ.,συμβαίνουν όταν αποστέλλονται μη αξιόπιστα δεδομένα σε έναν διερμηνέα
λογισμικού ως μέρος μιας εντολής ή ερωτήματος (query). Τα κακόβουλα δεδομένα
του εισβολέα μπορούν να ξεγελάσουν τον διερμηνέα ώστε να εκτελέσει ακούσιες
εντολές ή να αποκτήσει πρόσβαση σε δεδομένα χωρίς την κατάλληληεξουσιοδότηση.

API9:2019 - Improper Assets ManagementΤα APIs τείνουν να εκθέτουν περισσότερα τελικά σημεία προορισμού (endpoints)από τις παραδοσιακές εφαρμογές Ιστού, καθιστώντας τη σωστή και ενημερωμένη
τεκμηρίωση (documentation) εξαιρετικά σημαντική. Επίσης σημαντικό ρόλο για τονμετριασμό ελαττωμάτων όπως οι καταργημένες εκδόσεις APIs και τα εκτεθειμένα
τελικά σημεία εντοπισμού σφαλμάτων είναι η μεθοδική καταγραφή των servers καιτων εκδόσεων APIs που έχουν αναπτυχθεί.

API10:2019 - Insufficient Logging & MonitoringΗ ανεπαρκής καταγραφή και παρακολούθηση/εποπτεία, σε συνδυασμό με τηνέλλειψη ή την αναποτελεσματική ενσωµάτωση και διαλειτουργικότητα με τηναντιμετώπιση συμβάντων (incident response), επιτρέπει στους επιτιθέμενους ναεπεκτείνουν τις επιθέσεις τους, να διατηρήσουν την πρόσβαση τους, να στραφούν σεπερισσότερα συστήματα για να παραβιάσουν, να εξαγάγουν ή να καταστρέψουν
δεδομένα. Οι περισσότερες μελέτες παραβίασης αποδεικνύουν ότι ο μέσος χρόνος
που απαιτείται για τον εντοπισμό μιας παραβίασης ξεπερνάει τις 200 ημέρες καισυνήθως εντοπίζεται από εξωτερικούς συνεργάτες και όχι από ενδοεταιρικές
διαδικασίες ή παρακολούθηση/εποπτεία των συστημάτων.

API1:2019 Broken Object Level Authorization
ThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα : 2 Επιπτώσεις
την Επιχείρηση
:3Οι εισβολείς μπορούν ναΑυτή είναι η πιο κοινή και ιδιαίτεραΗ μη εξουσιοδοτημένη
εκμεταλλευτούν τελικά σημεία αποτελεσματική επίθεση σε API. Οιπρόσβαση μπορεί να οδηγήσει
προορισμού API (endpoints) που μηχανισμοί εξουσιοδότησης και ελέγχου
σε αποκάλυψη δεδομένων σεείναι ευάλωτα σε εσφαλμένη
πρόσβασης στις σύγχρονες εφαρμογές είναι μη εξουσιοδοτημένα μέρη,εξουσιοδότηση επιπέδου
περίπλοκοι και ευρέως διαδεδομένοι. Ακόμα απώλεια δεδομένων ήαντικειμένου (Broken Objectκι αν η εφαρμογή εφαρμόζει μια κατάλληλη παραποίηση δεδομένων. Η μη
Level Authorization),υποδομή για ελέγχους εξουσιοδότησης, οι εξουσιοδοτημένη πρόσβαση σεπαραποιώντας το αναγνωριστικό προγραμματιστές μπορεί να ξεχάσουν νααντικείμενα μπορεί επίσης ναενός αντικειμένου (object ID)χρησιμοποιήσουν αυτούς τους ελέγχους
οδηγήσει τους επιτιθέμενους
που αποστέλλεται εντός ενόςπριν παραχωρήσουν πρόσβαση σε ένανα αποκτήσουν πλήρη
αιτήματος (request). Αυτό μπορεί ευαίσθητο/διαβαθμισμένο αντικείμενο. Ηπρόσβαση του λογαριασμού
να οδηγήσει σε μηανίχνευση ελέγχου πρόσβασης συνήθως δεν ενός χρήστη (accountεξουσιοδοτημένη πρόσβαση σε υπόκειται σε αυτοματοποιημένους
takeover).
ευαίσθητα δεδομένα. Αυτό τοστατικούς ή δυναμικούς ελέγχους (static orκενό ασφαλείας είναι εξαιρετικά dynamic testing).
κοινό σε εφαρμογές πουβασίζονται σε API, επειδή οδιακομιστής (server) συνήθως
δεν έχει γνώση της κατάστασης
της εφαρμογής-πελάτη και, αντ'αυτού, βασίζεται σε παραμέτρους
όπως τα αναγνωριστικά
αντικειμένων, που
αποστέλλονται από τηνεφαρμογή-πελάτη για να
αποφασίσει σε ποια αντικείμενα
θα έχει πρόσβαση.
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα : 3Επικράτηση
(Prevalence): 3Πότε το API είναι ευάλωτο
Η εξουσιοδότηση επιπέδου αντικειμένου (Object Level Authorization) είναι ένας μηχανισμός ελέγχου
πρόσβασης που συνήθως υλοποιείται σε επίπεδο κώδικα για να επιβεβαιώσει ότι ένας χρήστης μπορεί να έχειπρόσβαση μόνο σε αντικείμενα (objects) στα οποία θα έπρεπε να έχει πρόσβαση.
Κάθε τελικό σημείο προορισμού API (endpoint) που λαμβάνει ένα αναγνωριστικό ενός αντικειμένου (objectID) και εκτελεί οποιονδήποτε τύπο ενέργειας στο αντικείμενο, θα πρέπει να εφαρμόζει ελέγχους
εξουσιοδότησης σε επίπεδο αντικειμένου. Οι έλεγχοι θα πρέπει να επικυρώνουν ότι ο συνδεδεμένος χρήστης
έχει πρόσβαση για να εκτελέσει την απαιτούμενη ενέργεια στο ζητούμενο αντικείμενο.
Οι αποτυχίες σε αυτόν τον μηχανισμό συνήθως οδηγούν σε μη εξουσιοδοτημένη αποκάλυψη πληροφοριών,τροποποίηση ή καταστροφή όλων των δεδομένων.

Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Μια πλατφόρμα ηλεκτρονικού εμπορίου για ηλεκτρονικά καταστήματα παρέχει μια σελίδα με τα διαγράμματαεσόδων για τα καταστήματα που φιλοξενεί. Επιθεωρώντας τα αιτήματα του προγράμματος περιήγησης

API1:2019 Broken Object Level Authorization(browser requests), ένας εισβολέας μπορεί να αναγνωρίσει τα τελικά σημεία προορισμού API (endpoints) πουχρησιμοποιούνται ως πηγή δεδομένων για αυτά τα γραφήματα και το μοτίβο URL τους το οποίο είναι τηςμορφής: /shops/{shopName}/revenue_data.json. Χρησιμοποιώντας ένα άλλο τελικό σημείο
προορισμού API (endpoint), ο εισβολέας λαμβάνει τη λίστα με όλα τα ονόματα καταστημάτων πουφιλοξενούνται. Ο εισβολέας χρησιμοποιεί ένα απλό script, το οποίο διαχειρίζεται τα ονόματα στη λίστα,αντικαθιστώντας το {shopName} στη διεύθυνση URL. Με αυτό τον τρόπο αποκτά πρόσβαση στα δεδομένα
πωλήσεων χιλιάδων καταστημάτων ηλεκτρονικού εμπορίου.

Σενάριο Επίθεσης #2
Κατά την παρακολούθηση της κυκλοφορίας δικτύου μιας φορητής συσκευής, το ακόλουθο αίτημα HTTP
PATCH τραβά την προσοχή ενός εισβολέα λόγω της παρουσίας μιας custom κεφαλίδας αιτήματος HTTP
X-User-Id: 54796. Αντικαθιστώντας την τιμή X-User-Id με 54795, ο εισβολέας λαμβάνει μιαεπιτυχημένη απάντηση HTTP και μπορεί να τροποποιήσει τα δεδομένα λογαριασμού άλλων χρηστών.

Τρόπος Πρόληψης
• Δημιουργήστε έναν σωστό μηχανισμό εξουσιοδότησης που βασίζεται στις πολιτικές των χρηστών (userpolicies) και την ιεραρχία τους.
• Χρησιμοποιήστε έναν μηχανισμό εξουσιοδότησης σε κάθε συνάρτηση (function) που χρησιμοποιεί
δεδομένα εισόδου από τη εφαρμογή-πελάτη (client) για να αποκτήσει πρόσβαση σε μια εγγραφή στηβάση δεδομένων. Ο μηχανισμός πρέπει να ελέγχει εάν ο συνδεδεμένος χρήστης έχει πρόσβαση ναεκτελέσει την απαιτούμενη ενέργεια στην εγγραφή.
• Προτιμήστε να χρησιμοποιείτε τυχαίες και απρόβλεπτες τιμές ως GUID για τα αναγνωριστικά (object
IDs) των εγγραφών.
• Γράψτε αυτοματοποιημένους ελέγχους (tests) για την αξιολόγηση του μηχανισμού εξουσιοδότησης.
Μην βγάζετε στην παραγωγή (deploy) ευάλωτες αλλαγές που σπάνε τα tests.

Αναφορές (References)Εξωτερικές Αναφορές
• CWE-284: Improper Access Control• CWE-285: Improper Authorization• CWE-639: Authorization Bypass Through User-Controlled Key

API2:2019 Broken User Authentication
ThreatAgentsΕξαρτώνταιαπό το API

AttackVectorsΕκμεταλλευσιμότητα: 3

Security
WeaknessΕπικράτηση
(Prevalence): 2

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα : 2 Επιπτώσεις
την Επιχείρηση
:3

Ο έλεγχος ταυτότητας στα APIsΥπάρχουν δύο υποκατηγορίες του κενού
Οι εισβολείς μπορούν ναείναι ένας πολύπλοκος και
ασφαλείας: 1. Έλλειψη μηχανισμών
αποκτήσουν τον έλεγχο
μπερδεμένος μηχανισμός. Οιπροστασίας: Τα τελικά σημεία προορισμού APIs λογαριασμών άλλων χρηστών στομηχανικοί λογισμικού και ασφαλείας που είναι υπεύθυνα για τον έλεγχο ταυτότητας σύστημα, να διαβάσουν ταενδέχεται να έχουν λανθασμένες
πρέπει να αντιμετωπίζονται διαφορετικά από τα προσωπικά τους δεδομένα και νααντιλήψεις σχετικά με τα όρια του κανονικά τελικά σημεία προορισμού και ναεκτελέσουν ευαίσθητες /ελέγχου ταυτότητας και πώς να τον εφαρμόζουν επιπλέον επίπεδα προστασίας. 2.
διαβαθμισμένες ενέργειες γιαεφαρμόσουν σωστά. Επιπλέον, οΕσφαλμένη εφαρμογή του μηχανισμού: Ολογαριασμό τους, όπωςμηχανισμός ελέγχου ταυτότητας
μηχανισμός χρησιμοποιείται / υλοποιείται χωρίς συναλλαγές χρημάτων καιείναι ένας εύκολος στόχος για τους να λαμβάνονται υπόψη τα διανύσματα επίθεσης αποστολή προσωπικών
εισβολείς, καθώς είναι προσβάσιμος (attack vectors) ή είναι λάθος η περίπτωση
μηνυμάτων.
σε όλους. Αυτοί οι δύο λόγοι
χρήσης του (π.χ. ένας μηχανισμός ελέγχου
καθιστούν τον μηχανισμό ελέγχου ταυτότητας που έχει σχεδιαστεί για εφαρμογέςταυτότητας δυνητικά ευάλωτο σεπελάτες (clients) IoT μπορεί να μην είναι ηπολλές επιθέσεις (exploits).
σωστή επιλογή για εφαρμογές Ιστού).

Πότε το 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) κωδικών πρόσβασης.

API2:2019 Broken User AuthenticationΣενάριο Επίθεσης #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.

Αναφορές (References)Αναφορές OWASP• OWASP Key Management Cheat Sheet• OWASP Authentication Cheatsheet• Credential StuffingΕξωτερικές Αναφορές
• CWE-798: Use of Hard-coded Credentials

API3:2019 Excessive Data Exposure
ThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 2 Επιπτώσεις:την Επιχείρηση
2Η εκμετάλλευση (exploitation) Το κενό ασφαλείας εμφανίζεται όταν APIs Η υπερβολική έκθεσητης υπερβολικής έκθεσης
βασίζονται στις εφαρμογές-πελάτες (client) δεδομένων οδηγεί συνήθως σεδεδομένων (Excessive Dataγια την εκτέλεση του φιλτραρίσματοςέκθεση ευαίσθητων δεδομένων.
Exposure) είναι απλή καιδεδομένων. Δεδομένου ότι τα APIsσυνήθως πραγματοποιείται
χρησιμοποιούνται ως πηγές δεδομένων,ανιχνεύοντας και αναλύοντας την συχνά οι προγραμματιστές προσπαθούν νακίνηση των δεδομένων πουτα υλοποιήσουν με γενικό τρόπο χωρίς ναεπιστρέφονται από το API στον σκεφτούν την ευαισθησία των δεδομένων
χρήστη. Στόχος της ανάλυσηςπου εκτίθενται. Τα αυτόματα εργαλεία
των δεδομένων είναι ησυνήθως δεν μπορούν να εντοπίσουν αυτόν
αναζήτηση πιθανής έκθεσης σε τον τύπο ευπάθειας, επειδή είναι δύσκολοευαίσθητα δεδομένα που δεννα γίνει διάκριση μεταξύ των μηπρέπει να επιστραφούν στονευαίσθητων δεδομένων που επιστρέφονται
χρήστη.
από το API και των ευαίσθητων δεδομένωνπου δεν πρέπει να επιστραφούν. Ηδυσκολία αυτή προκύπτει επειδή τααυτόματα εργαλεία δεν κατανοούν σεβάθος την εφαρμογή.
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 3Επικράτηση
(Prevalence): 2Πότε το API είναι ευάλωτο
Το API επιστρέφει ευαίσθητα δεδομένα στην εφαρμογή-πελάτη (client) βάσει σχεδίασης. Αυτά τα δεδομένα
συνήθως φιλτράρονται από την πλευρά της εφαρμογής-πελάτη πριν παρουσιαστούν στον χρήστη. Έναςεισβολέας μπορεί εύκολα να δει τα ευαίσθητα δεδομένα ανιχνεύοντας την κίνηση.

Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Η ομάδα που ασχολείται με το development για κινητά χρησιμοποιεί το τελικό σημείο προορισμού
/api/articles/{articleId}/comments/{commentId} στην σελίδα προβολής άρθρων για τηνεμφάνιση των μεταδεδομένων των σχολίων. Ανιχνεύοντας την κίνηση της εφαρμογής για κινητά, έναςεισβολέας ανακαλύπτει ότι επιστρέφονται και άλλα ευαίσθητα δεδομένα που σχετίζονται με τον συντάκτη τουσχολίου. Η υλοποίηση τελικού σημείου προορισμού (endpoint), χρησιμοποιεί μια γενική μέθοδο toJSON()για τη σειριοποίηση (serialization) του αντικειμένου στο μοντέλο User, το οποίο περιέχει ευαίσθητα δεδομένα
(PII).

Σενάριο Επίθεσης #2
Ένα σύστημα επιτήρησης που βασίζεται στο IOT επιτρέπει στους διαχειριστές να δημιουργούν χρήστες μεδιαφορετικά δικαιώματα. Ένας διαχειριστής δημιούργησε έναν λογαριασμό χρήστη για έναν νέο φύλακα πουθα πρέπει να έχει πρόσβαση μόνο σε συγκεκριμένα κτίρια στον ιστότοπο. Μόλις ο φύλακας χρησιμοποιήσει
την εφαρμογή του για κινητά, ενεργοποιείται μια κλήση API στη διεύθυνση: /api/sites/111/camerasπροκειμένου να ληφθούν δεδομένα σχετικά με τις διαθέσιμες κάμερες και να εμφανίστουν στον πίνακα
ελέγχου. Η απάντηση περιέχει μια λίστα με λεπτομέρειες σχετικά με τις κάμερες στην ακόλουθη μορφή:{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}. Ενώ το GUI

API3:2019 Excessive Data Exposureτης εφαρμογής-πελάτη εμφανίζει μόνο κάμερες στις οποίες θα πρέπει να έχει πρόσβαση ο φύλακας, ηπραγματική απόκριση API περιέχει μια πλήρη λίστα με όλες τις κάμερες στον ιστότοπο.

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

•

Μην βασίζεστε ποτέ στην πλευρά της εφαρμογής-πελάτη για να φιλτράρετε ευαίσθητα δεδομένα.
Ελέγξτε τις απαντήσεις από το API για να βεβαιωθείτε ότι περιέχουν μόνο αποδεκτά δεδομένα.
Οι back-end προγραμματιστές θα πρέπει πάντα να διερωτόνται "ποιος είναι ο καταναλωτής τωνδεδομένων;", πριν εκθέσουν δημόσια ένα νέο τελικό σημείο προορισμού API.
Αποφύγετε τη χρήση γενικών μεθόδων όπως to_json() και to_string(). Αντίθετα, επιλέξτε
συγκεκριμένα πεδία που θέλετε πραγματικά να επιστρέψετε.
Ταξινομήστε όλες τις ευαίσθητες και προσωπικά αναγνωρίσιμες πληροφορίες (PII) τις οποίες
αποθηκεύει και συνεργάζεται η εφαρμογή σας, ελέγχοντας όλες τις κλήσεις API που επιστρέφουν
τέτοιες πληροφορίες για να δείτε εάν αυτές οι απαντήσεις δημιουργούν πρόβλημα ασφαλείας.
Εφαρμόστε έναν μηχανισμό επικύρωσης απόκρισης που βασίζεται σε σχήματα (schema-based) ως έναεπιπλέον επίπεδο ασφαλείας. Ως μέρος αυτού του μηχανισμού ορίστε και επιβάλλετε δεδομένα πουεπιστρέφονται από όλες τις μεθόδους API, συμπεριλαμβανομένων των σφαλμάτων.

Αναφορές (References)Εξωτερικές Αναφορές
•CWE-213: Intentional Information ExposureAPI4:2019 Lack of Resources & Rate LimitingThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 3 Επιπτώσεις
την Επιχείρηση
:2Η εκμετάλλευση (exploitation) Είναι σύνηθες να βρίσκουμε API που δεν Η εκμετάλλευση (exploitation)αυτής της αδυναμίας ασφαλείας εφαρμόζουν περιορισμό ρυθμού (rateμπορεί να οδηγήσει σεαπαιτεί μόνο την αποστολή
limiting) ή APIs όπου τα όρια περιορισμού επιθέσεις άρνησης υπηρεσιών
απλών αιτημάτων (requests) στο δεν έχουν οριστεί σωστά.
(DoS), καθιστώντας το API μη
API. Δεν απαιτείται έλεγχος
ανταποκρινόμενο ή ακόμη καιταυτότητας. Πολλαπλάμη διαθέσιμο.
ταυτόχρονα αιτήματα (requests)
μπορούν να αποσταλούν απόέναν μόνο τοπικό υπολογιστή ήχρησιμοποιώντας πόρους
υπολογιστικού νέφους (cloudcomputing).
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 2Επικράτηση
(Prevalence): 3Πότε το API είναι ευάλωτο
Τα αιτήματα (requests) API καταναλώνουν πόρους (resources) όπως πόρους δικτύου, επεξεργαστή (CPU),μνήμης και αποθήκευσης. Το ποσό των πόρων που απαιτούνται για την ολοκλήρωση ενός αιτήματος εξαρτάται
σε μεγάλο βαθμό από τα δεδομένα εισόδου του χρήστη και την επιχειρηματική λογική (business logic) τουτελικού σημείου προορισμού (endpoint). Επίσης, λάβετε υπόψη το γεγονός ότι τα αιτήματα από πολλαπλούς
πελάτες API ανταγωνίζονται για τους πόρους του συστήματος. Ένα API είναι ευάλωτο εάν τουλάχιστον ένααπό τα ακόλουθα όρια περιορισμού λείπει ή τα όρια περιορισμού δεν έχουν οριστεί καταλλήλως (π.χ. πολύχαμηλά/υψηλά):
•
•
•
•
•
•
•

Χρονικά όρια εκτέλεσης (execution timeouts)Μέγιστο ποσό δέσμευσης μνήμης
Αριθμός περιγραφέων αρχείου (file descriptors)Αριθμός διεργασιών (processes)Μέγεθος αιτήματος ωφέλιμου φορτίου (request payload size) (π.χ. μεταφορτώσεις (uploads))Αριθμός αιτημάτων ανά πρόγραμμα-πελάτη/πόρο συστήματοςΑριθμός εγγραφών ανά σελίδα που περιέχονται σε κάθε απάντηση αιτήματος (request response)Παραδείγματα από Σενάρια Επίθεσης
Σενάριο #1
Ένας εισβολέας ανεβάζει μια μεγάλη εικόνα υποβάλλοντας ένα αίτημα POST στο /api/v1/images. Ότανολοκληρωθεί η μεταφόρτωση, το API δημιουργεί πολλές μικρογραφίες (thumbnails) με διαφορετικά μεγέθη.
Λόγω του μεγάλου μεγέθους της μεταφορτωμένης εικόνας, η διαθέσιμη μνήμη του συστήματος εξαντλείται
κατά τη δημιουργία μικρογραφιών και το API σταματάει να ανταποκρίνεται.

Σενάριο #2
Έχουμε μια εφαρμογή που περιέχει τη λίστα χρηστών σε μια διεπαφή χρήστη (UI) με όριο 200 χρήστες ανάσελίδα. Η λίστα των χρηστών ανακτάται από τον διακομιστή (server) χρησιμοποιώντας το ακόλουθο ερώτημα:/api/users?page=1&size=200. Ένας εισβολέας αλλάζει την παράμετρο μεγέθους σε 200 000,προκαλώντας προβλήματα απόδοσης (performance) στη βάση δεδομένων. Τα προβλήματα απόδοσης της βάσης

API4:2019 Lack of Resources & Rate Limitingδεδομένων σταματούν το API από το να ανταποκρίνεται και το API δεν είναι πλέον σε θέση να χειριστεί
περαιτέρω αιτήματα από τον τρέχων ή άλλους πελάτες (γνωστό και ως DoS).
Το ίδιο σενάριο μπορεί να χρησιμοποιηθεί για την πρόκληση σφαλμάτων υπερχείλισης ακεραίων (Integer
Overflow) ή υπερχείλισης buffer (Buffer Overflow).

Τρόπος Πρόληψης• Το Docker διευκολύνει τον περιορισμό της μνήμης, του επεξεργαστή CPU, τον αριθμό
εππανεκκινήσεων, των περιγραφέων αρχείου (file descriptors), και διεργασιών (processes).
• Εφαρμόστε ένα όριο περιορισμού σχετικά με το πόσο συχνά ένα πρόγραμμα-πελάτης μπορεί να καλεί
το API εντός ενός καθορισμένου χρονικού πλαισίου.
• Ειδοποιήστε το πρόγραμμα-πελάτη όταν γίνεται υπέρβαση του ορίου παρέχοντας τον αριθμό ορίου καιτην ώρα κατά την οποία θα γίνει επαναφορά του ορίου.
• Προσθέστε την κατάλληλη επικύρωση (validation) από την πλευρά του διακομιστή για τις παραμέτρους
συμβολοσειράς ερωτήματος (query string) και σώματος αιτήματος (request body), ειδικά αυτή πουελέγχει τον αριθμό των εγγραφών που θα επιστραφούν στην απάντηση.
• Καθορίστε και επιβάλλετε μέγιστο μέγεθος δεδομένων σε όλες τις εισερχόμενες παραμέτρους καιωφέλιμα φορτία (payloads), όπως το μέγιστο μήκος για τις συμβολοσειρές (strings) και τον μέγιστοαριθμό στοιχείων σε πίνακες (elements in arrays).

Αναφορές (References)Αναφορές OWASP• Blocking Brute Force Attacks• Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, processes, restarts)• REST Assessment Cheat SheetΕξωτερικές Αναφορές
• CWE-307: Improper Restriction of Excessive Authentication Attempts• CWE-770: Allocation of Resources Without Limits or Throttling• “Rate Limiting (Throttling)” - Security Strategies for Microservices-based Application Systems, NISTAPI5:2019 Broken Function Level Authorization
ThreatAgentsΕξαρτώνταιαπό το API

AttackVectorsΕκμεταλλευσιμότητα: 3

Security
WeaknessΕπικράτηση
(Prevalence): 2

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

Πότε το 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}. Η απάντηση περιέχει ένα

API5:2019 Broken Function Level Authorization
JSON με λεπτομέρειες σχετικές με την πρόσκληση, συμπεριλαμβανομένου του ρόλου του χρήστη και του email τουχρήστη.
Ένας εισβολέας αντέγραψε το αίτημα και άλλαξε τη μέθοδο HTTP και το τελικό σημείο σε POST
/api/invites/new. Αυτό το τελικό σημείο προορισμού θα πρέπει να είναι προσβάσιμο μόνο από διαχειριστές πουχρησιμοποιούν την κονσόλα διαχείρισης, το οποίο όμως τελικό σημείο προορισμού δεν εφαρμόζει ελέγχους
εξουσιοδότησης σε επίπεδο λειτουργίας.
Ο εισβολέας εκμεταλλεύεται το πρόβλημα και στέλνει στον εαυτό του μια πρόσκληση για να δημιουργήσει ένανλογαριασμό διαχειριστή:POST /api/invites/new{“email”:”hugo@malicious.com”,”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•OWASP Article on Forced Browsing•

OWASP Top 10 2013-A7-Missing Function Level Access Control•

OWASP Development Guide: Chapter on Authorization

External•

CWE-285: Improper Authorization

API6:2019 Mass Assignment
ThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 2 Επιπτώσεις
την Επιχείρηση
:2Η εκμετάλλευση (exploitation) Τα σύγχρονα frameworks ενθαρρύνουν
Η εκμετάλλευση (exploitation)αυτής της αδυναμίας ασφαλείας τους προγραμματιστές να χρησιμοποιούν μπορεί να οδηγήσει σεσυνήθως απαιτεί κατανόηση της συναρτήσεις (functions) που συνδέουν
κλιμάκωση των προνομίων
επιχειρησιακής λογικής (business αυτόματα την είσοδο από τον χρήστη ή την (privilege escalation),
logic), των σχέσεων τωνεφαρμογή-πελάτη (client) σε μεταβλητές
παραποίηση δεδομένων (dataαντικειμένων και της δομής του κώδικα και εσωτερικά αντικείμενα. Οιtampering), παράκαμψη
API. Η εκμετάλλευση τηςεισβολείς μπορούν να χρησιμοποιήσουν
μηχανισμών ασφαλείας καιμαζικής εκχώρησης (Massαυτήν τη μεθοδολογία για να ενημερώσουν πολλά άλλα.
Assignment) είναι ευκολότερηή να αντικαταστήσουν τις τιμές ευαίσθητωνστα APIs, καθώς από τοιδιοτήτων αντικειμένων (object properties),σχεδιασμό τους εκθέτουν τηντις οποίες οι προγραμματιστές δενυλοποίηση της εφαρμογής μαζί σκόπευαν ποτέ να εκθέσουν στους χρήστες.
με τα ονόματα των ιδιοτήτων
(properties).
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 2Επικράτηση
(Prevalence): 2Πότε το API είναι ευάλωτο
Τα αντικείμενα (objects) στις σύγχρονες εφαρμογές μπορεί να περιέχουν πολλές ιδιότητες (properties).
Ορισμένες από αυτές τις ιδιότητες θα πρέπει να μπορούν να ενημερώνονται απευθείας από την εφαρμογήπελάτη (client) (π.χ. user.first_name ή user.address) και ορισμένες από αυτές δεν θα πρέπει ναείναι προσβάσιμες στους χρήστες / εφαρμογές-πελάτες (π.χ. user.is_vip).
Ένα τελικό σημείο προορισμού API είναι ευάλωτο εάν μετατρέπει αυτόματα τις παραμέτρους της εφαρμογήςπελάτη σε ιδιότητες εσωτερικού αντικειμένου, χωρίς να λαμβάνεται υπόψη η ευαισθησία και το επίπεδο
έκθεσης αυτών των ιδιοτήτων. Αυτό θα μπορούσε να επιτρέψει σε έναν εισβολέα να ενημερώσει τις ιδιότητες
αντικειμένων (object properties), στις οποίες δεν θα έπρεπε να έχει πρόσβαση.
Παραδείγματα ευαίσθητων ιδιοτήτων (properties):• Ιδιότητες που σχετίζονται με δικαιώματα: Τα user.is_admin, user.is_vip θα πρέπει ναορίζονται μόνο από διαχειριστές.
• Ιδιότητες που εξαρτώνται από κάποια διαδικασία (process): Το user.cash θα πρέπει να ορίζεται
εσωτερικά μόνο μετά την επαλήθευση πληρωμής.
• Εσωτερικές ιδιότητες: Η ιδιότητα article.created_time θα πρέπει να επιτρέπεται να ορίζεται
μόνο εσωτερικά από την εφαρμογή.

Παραδείγματα Σεναρίων Επίθεσης
Σενάριο Επίθεσης #1Μια εφαρμογή διαμοιρασμού διαδρομής (ride sharing) παρέχει στον χρήστη την επιλογή να επεξεργαστεί
βασικές πληροφορίες για το προφίλ του. Κατά τη διάρκεια αυτής της διαδικασίας, αποστέλλεται μια κλήση APIστο PUT /api/v1/users/me με το ακόλουθο έγκυρο αντικείμενο JSON:{"user_name":"inons","age":24}Το αίτημα GET /api/v1/users/me περιλαμβάνει μια πρόσθετη ιδιότητα credit_balance:

API6:2019 Mass Assignment{"user_name":"inons","age":24,"credit_balance":10}Ο εισβολέας επαναλαμβάνει το πρώτο αίτημα με το ακόλουθο payload:{"user_name":"attacker","age":60,"credit_balance":99999}

Δεδομένου ότι το τελικό σημείο προορισμού είναι ευάλωτο σε μαζική εκχώρηση (Mass Assignment), οεισβολέας λαμβάνει πιστώσεις (credits) χωρίς να πληρώσει.

Σενάριο Επίθεσης #2
Ένα portal διαμοιρασμού βίντεο (video sharing portal) επιτρέπει στους χρήστες να ανεβάζουν περιεχόμενο καινα κατεβάζουν περιεχόμενο σε διαφορετικές μορφές (formats). Ένας εισβολέας που εξερευνά το APIδιαπίστωσε ότι το τελικό σημείο προορισμού GET /api/v1/videos/{video_id}/meta_data
επιστρέφει ένα αντικείμενο JSON με τις ιδιότητες του βίντεο. Μία από τις ιδιότητες είναι
"mp4_conversion_params":"-v codec h264", που υποδεικνύει ότι η εφαρμογή χρησιμοποιεί μιαεντολή shell για τη μετατροπή του βίντεο.
Ο εισβολέας διαπίστωσε επίσης ότι το τελικό σημείο προορισμού POST /api/v1/videos/new είναι
ευάλωτο σε μαζική εκχώρηση (Mass Assignment) και επιτρέπει στην εφαρμογή-πελάτη (client) να ορίσει
οποιαδήποτε ιδιότητα του αντικειμένου βίντεο. Ο εισβολέας ορίζει μια κακόβουλη τιμή ως εξής:"mp4_conversion_params":"-v codec h264 && format C:/". Αυτή η τιμή θα προκαλέσει
μια έγχυση εντολής shell (shell command injection) μόλις ο εισβολέας κατεβάσει το βίντεο ως MP4.

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

•Δημιουργήστε μια λίστα επιτρεπόμενων (whitelist) ιδιοτήτων που να περιλαμβάνει μόνο τις ιδιότητεςπου επιτρέπεται να ενημερώνονται από τους χρήστες / εφαρμογές-πελάτες (API clients).

•Χρησιμοποιήστε ενσωματωμένες δυνατότητες του framework σας για να δημιουργήσετε μια λίστα μηεπιτρεπόμενων ιδιοτήτων στις οποίες δεν πρέπει να έχουν πρόσβαση οι εφαρμογές-πελάτες (APIclients).

•Εάν είναι εφικτό, ορίστε και επιβάλλετε ρητά σχήματα (schemas) για τα payloads δεδομένων εισόδου.

Αναφορές (References)Εξωτερικές Αναφορές
•CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

API7:2019 Security Misconfiguration
ThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 3 Επιπτώσεις
την Επιχείρηση
:2Οι εισβολείς συχνά επιχειρούν να Λανθασμένες ρυθμίσεις παραμέτρων
Οι εσφαλμένες ρυθμίσεις
βρουν μη επιδιορθωμένα
ασφαλείας (Security Misconfigurations)
ασφαλείας όχι μόνο εκθέτουν
ελαττώματα (unpatched flows), μπορούν να υπάρξουν σε οποιοδήποτε
ευαίσθητα δεδομένα χρηστών,συνηθισμένα τελικά σημεία
επίπεδο της στοίβας API (API stack), από αλλά εκθέτουν καιπροορισμού ή μη προστατευμένα το επίπεδο δικτύου έως το επίπεδο
λεπτομέρειες συστήματος πουαρχεία και καταλόγους για ναεφαρμογής. Διατίθενται αυτοματοποιημένα μπορεί να οδηγήσουν σε πλήρη
αποκτήσουν μη εξουσιοδοτημένη εργαλεία για τον εντοπισμό και τηνπαραβίαση του διακομιστή
πρόσβαση ή γνώση τουεκμετάλλευση εσφαλμένων διαμορφώσεων, (server).
συστήματος.
όπως περιττές υπηρεσίες ή ρυθμίσεις
παλαιού τύπου (legacy options).
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 3Επικράτηση
(Prevalence): 3Πότε το API είναι ευάλωτο
Το API μπορεί να είναι ευάλωτο όταν:• Δεν υπάρχει η κατάλληλη θωράκιση ασφαλείας (security hardening) σε όλα τα τμήματα της στοίβας τηςεφαρμογής, ή υπάρχουν λανθασμένες ρυθμίσεις δικαιωμάτων σε υπηρεσίες Cloud.
• Δεν έχουν εγκατασταθεί οι ενημερωμένες εκδόσεις ασφαλείας, ή τα συστήματα είναι παροχημένα.
• Αχρείαστα χαρακτηριστικά (features) είναι ενεργοποιημένα (για παράδειγμα, το API δέχεται HTTP verbs που δενχρησιμοποιούνται).
• Δεν υπάρχει Transport Layer Security (TLS).
• Δεν στέλνονται στις εφαρμογές-πελάτες (clients) οι οδηγίες ασφαλείας (security directives)(π.χ., Επικεφαλίδες
Ασφαλείας).
• Δεν υπάρχει πολιτική Cross-Origin Resource Sharing (CORS) ή έχει ρυθμιστεί εσφαλμένα.
• Τα μηνύματα σφαλμάτων περιλαμβάνουν τεχνικές πληροφορίες για τα σφάλματα όπως τα ονόματα και τηναλληλουχία των μεθόδων εκτέλεσης (stack trace) ή το API εκθέτει άλλες ευαίσθητες πληροφορίες.

Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Ένας εισβολέας βρίσκει το αρχείο .bash_history κάτω από τον κεντρικό φάκελο (root folder) του διακομιστή, τοοποίο περιλαμβάνει εντολές που χρησιμοποιούνται από την ομάδα DevOps για να έχουν πρόσβαση στο API:$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic
Zm9vOmJhcg=='Ένας εισβολέας θα μπορούσε επίσης να βρει άγνωστα τελικά σημεία προορισμού του API που χρησιμοποιούνται μόνοαπο την ομάδα DevOps και τα οποία δεν είναι τεκμηριωμένα.

Σενάριο Επίθεσης #2
Θέτοντας ως στόχο μια συγκεκριμένη υπηρεσία, ένας εισβολέας χρησιμοποιεί μια δημοφιλή μηχανή αναζήτησης για νααναζητήσει υπολογιστές άμεσα προσβάσιμους από το Διαδίκτυο. Ο εισβολέας βρίσκει έναν διακομιστή που τρέχει έναδημοφιλές σύστημα διαχείρισης βάσεων δεδομένων, το οποίο ακούει στην προεπιλεγμένη θύρα. Ο διακομιστής αυτός
χρησιμοποιεί τις προεπιλεγμένες ρυθμίσεις (default configuration), οι οποίες έχουν απενεργοποιημένο τον έλεγχο
ταυτότητας, με αποτέλεσμα ο εισβολέας να αποκτήσει πρόσβαση σε εκατομμύρια εγγραφές με προσωπικά δεδομένα
(PII), προσωπικές προτιμήσεις και δεδομένα ελέγχου ταυτότητας.

API7:2019 Security MisconfigurationΣενάριο Επίθεσης #3
Επιθεωρώντας την μεταφορά των δεδομένων μιας εφαρμογής για κινητά, ένας εισβολέας ανακαλύπτει ότι τα δεδομένα
HTTP δεν μεταφέρονται ολικά κάτω από ένα ασφαλές πρωτόκολλο (π.χ. TLS). Ο εισβολέας ανακαλύπτει ότι αυτόσυμβαίνει ειδικά για τη λήψη εικόνων προφίλ. Καθώς η αλληλεπίδραση του χρήστη με το API είναι δυαδική και παρά το
γεγονός ότι η μεταφορά των δυαδικών δεδομένων του API εκτελείται κάτω από ένα ασφαλές πρωτόκολλο, ο εισβολέας
ανακαλύπτει ένα μοτίβο όσον αφορά το μέγεθος των απαντήσεων του API. Στην συνέχεια, ο εισβολέας χρησιμοποιεί τομοτίβο για να βγάζει συμπεράσματα για τις προτιμήσεις των χρηστών σε σχέση με το περιεχόμενο που εμφανίζεται (π.χ.
εικόνες προφίλ).

Τρόπος Πρόληψης
Με στόχο την αποτελεσματική πρόληψη, ο κύκλος ζωής των API θα πρέπει να περιλαμβάνει τα παρακάτω:• Επαναλαμβανόμενη διαδικασία θωράκισης (hardening) που επιτρέπει γρήγορη και εύκολη εγκατάσταση ενόςσωστά ασφαλισμένου περιβάλλοντος στο οποίο θα τρέχουν τα APIs.
• Έλεγχο και ενημέρωση των ρυθμίσεων σε ολόκληρη τη στοίβα (stack) των APIs. Ο έλεγχος θα πρέπει ναπεριλαμβάνει αρχεία που χρησιμοποιούνται κατά την ενορχήστρωση (orchestration), API components καιυπηρεσίες cloud (π.χ. δικαιώματα κάδων S3).
• Ένα ασφαλές κανάλι επικοινωνίας για όλες τις αλληλεπιδράσεις του API σε στατικά στοιχεία (π.χ. εικόνες).
• Αυτοματοποιημένη διαδικασία για τη συνεχή αξιολόγηση της αποτελεσματικότητας των ρυθμίσεων σε όλα ταπεριβάλλοντα.
Ακόμα:• Για να αποτρέψετε την πιθανή αποστολή τεχνικών πληροφοριών σε μηνύματα σφαλμάτων (exception trace) καιάλλων πολύτιμων πληροφοριών στους εισβολείς, εάν έχετε την δυνατότητα, ορίστε και επιβάλετε συγκρεκριμένα
σχήματα απαντήσεων API (response payload schemas), συμπεριλαμβανομένων των απαντήσεων σφαλμάτων
(error responses).
• Βεβαιωθείτε ότι το API είναι προσβάσιμο μόνο από τα ρήματα/μεθόδους HTTP (HTTP verbs) που έχετε
καθορίσει. Όλα τα άλλα ρήματα/μέθοδοι HTTP (HTTP verbs) θα πρέπει να είναι απενεργοποιημένα (π.χ.
"HEAD").
• Τα APIs που είναι σχεδιασμένα για να είναι προσβάσιμα από εφαρμογές-πελάτες μέσω προγραμμάτων
περιήγησης (π.χ., το front-end μιας εφαρμογής Web) θα πρέπει να εφαρμόζουν μια σωστή πολιτική κοινής
χρήσης πόρων μεταξύ προέλευσης (CORS).

Αναφορές (References)Αναφορές OWASP••••OWASP Secure Headers Project
OWASP Testing Guide: Configuration Management
OWASP Testing Guide: Testing for Error Codes
OWASP Testing Guide: Test Cross Origin Resource SharingΕξωτερικές Αναφορές
•
•
•
•
•

CWE-2: Environmental Security Flaws
CWE-16: Configuration
CWE-388: Error Handling
Guide to General Server Security, NIST
Let’s Encrypt: a free, automated, and open Certificate Authority

API8:2019 Injection
ThreatAgentsΕξαρτώνταιαπό το API

AttackVectorsΕκμεταλλευσιμότητα: 3

Security
WeaknessΕπικράτηση
(Prevalence): 2

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 3 Επιπτώσεις
την Επιχείρηση
:3Οι εισβολείς εισάγουν στο APIΟι ευπάθειες έγχυσης είναι πολύ κοινές καιΗ έγχυση (injection) μπορεί νακακόβουλα δεδομένα μέσωεντοπίζονται συχνά σε ερωτήματα SQL, LDAP οδηγήσει σε αποκάλυψη
οποιασδήποτε διαθέσιμης μεθόδου ή NoSQL, εντολές λειτουργικού συστήματος, πληροφοριών και απώλεια
εισαγωγής δεδομένων αναμένοντας αναλυτές XML και ORM. Αυτές οι ευπάθειες δεδομένων. Μπορεί επίσης νανα σταλούν τελικώς σε ένανείναι εύκολο να εντοπιστούν κατά τον έλεγχο οδηγήσει σε επιθέσεις άρνησης
διερμηνέα λογισμικού (interpreter). του πηγαίου κώδικα. Οι επιτιθέμενοι μπορούν εξυπηρέτησης (DoS) ή πλήρηΟι μέθοδοι αυτοί που μπορούν νανα χρησιμοποιήσουν σαρωτές και fuzzers για κατάληψη του κεντρικού
χρησιμοποιηθούν για εισαγωγή
να εντοπίσουν τέτοιες ευπάθειες.
υπολογιστή.
κακόβουλων δεδομένων πουκαταλήγουν σε διερμηνείς
λογισμικού ονομάζονται διανύσματαέγχυσης (injection vectors).
Παραδείγματα τέτοιων μεθόδων
είναι η άμεση εισαγωγή δεδομένων
(direct input), οι παράμετροι(parameters), οιολοκληρωμένες/ενσωματωμένες
υπηρεσίες (integrated services) κ.λπ.

Πότε το API είναι ευάλωτο
Το API είναι ευάλωτο σε ευπάθεια έγχυσης (injection flaw) όταν:• Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες δεν επικυρώνονται, δεν φιλτράρονται ή δεναπολυμαίνονται (sanitized) από το API.
• Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες χρησιμοποιούνται απευθείας ή συνδέονταιμε ερωτήματα SQL/NoSQL/LDAP, εντολές λειτουργικού συστήματος, αναλυτές XML και σχεσιακή αντιστοίχιση
αντικειμένων (ORM) / χαρτογράφηση εγγράφων αντικειμένου (ODM).
• Τα δεδομένα που προέρχονται από εξωτερικά συστήματα (π.χ. ολοκληρωμένα/ενσωματωμένα συστήματα) δενεπικυρώνονται (validation), δεν φιλτράρονται (filtering) ή δεν απολυμαίνονται (sanitization) από το API.

Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Το υλικολογισμικό (firmware) μιας συσκευής γονικού ελέγχου παρέχει το τελικό σημείο προορισμού
/api/CONFIG/restore το οποίο έχει σχεδιαστεί έτσι ώστε η παράμετρος appId να αποστέλεται ωςπαράμετρος πολλαπλών τμημάτων (multipart parameter). Χρησιμοποιώντας έναν απομεταγλωττιστή
(decompiler), ένας εισβολέας ανακαλύπτει ότι το appId περνάει απευθείας σε μια κλήση συστήματος χωρίς
καμία απολύμανση (sanitization):
snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d","/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);

Η ακόλουθη εντολή επιτρέπει στον εισβολέα να τερματίσει οποιαδήποτε συσκευή με το ίδιο ευάλωτο
υλικολογισμικό:$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F'appid=$(/etc/pod/power_down.sh)'API8:2019 InjectionΣενάριο Επίθεσης #2
Έχουμε μια εφαρμογή με βασική λειτουργικότητα CRUD για λειτουργίες με κρατήσεις (bookings). Ένας εισβολέας κατάφερε νααναγνωρίσει ότι η εισαγωγή NoSQL μπορεί να είναι δυνατή μέσω της παραμέτρου ερωτήματος bookingId στο αίτημα διαγραφής
κράτησης. To αίτημα είναι το εξής: DELETE /api/bookings?bookingId=678.
Ο διακομιστής API χρησιμοποιεί την ακόλουθη λειτουργία (function) για να χειριστεί αιτήματα διαγραφής:router.delete('/bookings', async function (req, res, next) {try {const deletedBooking = await Bookings.findOneAndRemove({_id' : req.query.bookingId});
res.status(200);} catch (err) {res.status(400).json({error: 'Unexpected error occured while processing a request'
});
}
});
Ο εισβολέας υπέκλεψε το αίτημα και άλλαξε την παράμετρο ερωτήματος bookingId, όπως φαίνεται παρακάτω. Σε αυτήν τηνπερίπτωση, ο εισβολέας κατάφερε να διαγράψει την κράτηση άλλου χρήστη:DELETE /api/bookings?bookingId[$ne]=678

Τρόπος ΠρόληψηςΗ πρόληψη της έγχυσης απαιτεί τη διατήρηση των δεδομένων ξεχωριστά από εντολές και ερωτήματα.
• Εκτελέστε επικύρωση (validation) δεδομένων χρησιμοποιώντας μια αξιόπιστη και ενεργά συντηρούμενη
βιβλιοθήκη.
• Όλα τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες ή άλλα δεδομένα που προέρχονται απόενσωματωμένα συστήματα πρέπει να επικυρώνονται (validation), φιλτράρονται ή/και να απολυμαίνονται
(sanitization).
• Οι ειδικοί χαρακτήρες θα πρέπει να διαφεύγονται (escape) χρησιμοποιώντας τη συγκεκριμένη σύνταξη τουδιερμηνέα λογισμικού που λαμβάνει τα δεδομένα.
• Προτιμήστε ένα ασφαλές API που παρέχει μια παραμετροποιημένη διεπαφή.
• Φροντίστε να περιορίσετε τον αριθμό των επιστρεφόμενων εγγραφών για να αποτρέψετε τη μαζική παραβίαση
δεδομένων σε περίπτωση επίθεσης.
• Επικυρώστε τα εισερχόμενα δεδομένα χρησιμοποιώντας επαρκή φίλτρα για να επιτρέπονται μόνο έγκυρες τιμές
για κάθε παράμετρο εισόδου.
• Ορίστε τύπους δεδομένων και αυστηρά μοτίβα για όλες τις παραμέτρους αιτημάτων.

Αναφορές (References)Αναφορές OWASP•OWASP Injection Flaws•

SQL Injection•

NoSQL Injection Fun with Objects and Arrays•

Command InjectionΕξωτερικές Αναφορές
•CWE-77: Command Injection•

CWE-89: SQL Injection

API9:2019 Improper Assets Management
ThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 2 Επιπτώσεις
την Επιχείρηση
:2Οι παλιές εκδόσεις ενός APIΗ μη ενημερωμένη τεκμηρίωση
Οι εισβολείς ενδέχεται ναμένουν συνήθως ανενημέρωτες (documentation) ενός API καθιστά πιοαποκτήσουν πρόσβαση σεαπό ενημερώσεις ασφαλείας
δύσκολη την εύρεση ή/και τη διόρθωση
ευαίσθητα δεδομένα ή ακόμη
(unpatched) και έτσι αποτελούν ευπαθειών. Η έλλειψη μεθοδικής
και πάρουν τον έλεγχο τουέναν εύκολο τρόπο για τηνκαταγραφής των πληροφοριακών στοιχείων διακομιστή μέσω παλιών, μη
παραβίαση συστημάτων χωρίς να (assets inventory) και η έλλειψηενημερωμένων εκδόσεων APIχρειάζεται ο εισβολέας ναστρατηγικών απόσυρσης (retire strategies) που συνδέονται στην ίδια βάσηαντιμετωπίσει μηχανισμούς
οδηγούν στο να τρέχουν ανενημέρωτα
δεδομένων.
ασφαλείας τελευταίας
(unpatched) συστήματα, με αποτέλεσμα τητεχνολογίας, οι οποίοι μπορεί να διαρροή ευαίσθητων δεδομένων. Είναι
υπάρχουν αλλά να προστατεύουν σύνηθες να βρίσκουμε άσκοπαμόνο τις νέες εκδόσεις ενός API. εκτεθειμένους κεντρικούς υπολογιστές APIλόγω των σύγχρονων concepts όπως ταmicroservices, τα οποία καθιστούν τιςεφαρμογές ανεξάρτητες και εύκολες στηνανάπτυξη (π.χ. υπολογιστικό νέφος (cloud),k8s).
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 3Επικράτηση
(Prevalence): 3Πότε το API είναι ευάλωτο
Το API ίσως είναι ευάλωτο όταν:• Ο σκοπός ενός κεντρικού υπολογιστή API είναι ασαφής και δεν υπάρχουν σαφείς απαντήσεις στις ακόλουθες
ερωτήσεις:• Σε ποιο περιβάλλον εκτελείται το API (π.χ. παραγωγή (production), σταδιοποίηση (staging), δοκιμή
(test), ανάπτυξη (development));• Ποιος πρέπει να έχει δικτυακή πρόσβαση στο API (π.χ. δημόσια πρόσβαση, εσωτερική πρόσβαση,πρόσβαση σε συνεργάτες);• Ποια έκδοση API εκτελείται;• Ποια δεδομένα συλλέγονται και επεξεργάζονται από το API (π.χ. Προσωπικά αναγνωρίσιμα στοιχεία
(PII));• Ποια είναι η ροή των δεδομένων;• Δεν υπάρχει τεκμηρίωση (documentation) ή η υπάρχουσα τεκμηρίωση δεν έχει ενημερωθεί.
• Δεν υπάρχει σχέδιο απόσυρσης (retirement plan) για κάθε έκδοση API.
• Δεν υπάρχει αρχείο καταγραφής όλων των hosts (hosts inventory) ή αν υπάρχει δεν είναι ενημερωμένο.
• Το αρχείο καταγραφής ολοκληρωμένων υπηρεσιών (integrated services inventory), είτε της εταιρίας που φτιάχνει
το API (first-party), είτε τρίτων μελών (third-party), λείπει ή είναι παλιό.
• Εκτελούνται παλιές ή προηγούμενες εκδόσεις του API χωρίς ενημέρωση.

Παραδείγματα Σεναρίων Επίθεσης
Σενάριο Επίθεσης #1
Μετά τον επανασχεδιασμό των εφαρμογών της, μια τοπική υπηρεσία αναζήτησης άφησε μια παλιά έκδοση API(api.someservice.com/v1) σε λειτουργία, απροστάτευτη και με πρόσβαση στη βάση δεδομένων των χρηστών.
Ένας εισβολέας, ενώ στόχευε μία από τις πιο πρόσφατες εφαρμογές που κυκλοφόρησαν, βρήκε τη διεύθυνση API(api.someservice.com/v2). Η αντικατάσταση του «v2» με το «v1» στη διεύθυνση URL έδωσε στον εισβολέα

API9:2019 Improper Assets Managementπρόσβαση στο παλιό, μη προστατευμένο API, εκθέτοντας τα προσωπικά στοιχεία ταυτοποίησης (PII) περισσότερων από
100 εκατομμυρίων χρηστών.

Σενάριο Επίθεσης #2
Ένα κοινωνικό δίκτυο εφάρμοσε έναν μηχανισμό περιορισμού ρυθμού (rate limiting) που εμποδίζει τους εισβολείς ναχρησιμοποιούν επιθέσεις ωμής βίας (brute force attacks) για να μαντέψουν τα διακριτικά επαναφοράς κωδικών
πρόσβασης. Αυτός ο μηχανισμός δεν εφαρμόστηκε ως μέρος του ίδιου του κώδικα API, αλλά σε ένα ξεχωριστό στοιχείο
(component) μεταξύ του πελάτη και του επίσημου API (www.socialnetwork.com). Ένας ερευνητής βρήκε ένανδεύτερο κεντρικό υπολογιστή (www.mbasic.beta.socialnetwork.com) που εκτελεί το ίδιο API,συμπεριλαμβανομένου του μηχανισμού επαναφοράς κωδικού πρόσβασης, αλλά χωρίς μηχανισμό περιορισμού ρυθμού. Οερευνητής μπόρεσε να επαναφέρει τον κωδικό πρόσβασης οποιουδήποτε χρήστη χρησιμοποιώντας μια απλή επίθεση
ωμής βίας για να μαντέψει το διακριτικό των 6 ψηφίων.

Τρόπος Πρόληψης• Καταγράψτε όλους τους υπολογιστές (hosts) που φιλοξενούν API. Καταγράψτε τα περιβάλλοντα που τρέχουν ταAPI (production, staging, test, development). Επίσης καταγράψτε ποιος θα πρέπει να έχει πρόσβαση σε αυτά(ανοιχτά σε όλους, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες) καθώς και την έκδοση τους.
• Καταγράψτε τις ολοκληρωμένες υπηρεσίες (integrated services) δηλαδή τις εξωτερικές υπηρεσίες πουχρησιμοποιούν το API. Τεκμηριώστε σημαντικές πτυχές τους όπως ο ρόλος τους στο σύστημα, ποια δεδομένα
ανταλλάσσονται (ροή δεδομένων) και η ευαισθησία τους.
• Τεκμηριώστε όλες τις πτυχές του API σας, όπως τον έλεγχο ταυτότητας, τα σφάλματα, τις ανακατευθύνσεις, τονπεριορισμό ρυθμού, την πολιτική και τα τελικά σημεία κοινής χρήσης πόρων μεταξύ προέλευσης (CORS),συμπεριλαμβανομένων των παραμέτρων, των αιτημάτων και των απαντήσεών τους.
• Δημιουργήστε τεκμηρίωση αυτόματα υιοθετώντας ανοιχτά πρότυπα (open standards). Συμπεριλάβετε τηναυτόματη δημιουργία τεκμηρίωσης στο σύστημα CI/CD σας.
• Παραχωρήστε πρόσβαση στην τεκμηρίωση API σε όσους είναι εξουσιοδοτημένοι να χρησιμοποιούν το API.
• Χρησιμοποιήστε εξωτερικά μέτρα προστασίας, όπως τείχη προστασίας ασφαλείας API για όλες τις εκτεθειμένες
εκδόσεις των API σας και όχι μόνο για την τρέχουσα έκδοση παραγωγής.
• Αποφύγετε τη χρήση δεδομένων παραγωγής σε μη παραγωγικές διανομές (deployments) του API. Εάν αυτό είναι
αναπόφευκτο, αυτά τα τελικά σημεία προορισμού θα πρέπει να τυγχάνουν της ίδιας μεταχείρισης ασφαλείας μεαυτά της παραγωγής.
• Όταν νεότερες εκδόσεις των API περιλαμβάνουν βελτιώσεις ασφαλείας, πραγματοποιήστε ανάλυση κινδύνου γιανα αποφασίσετε για τις ενέργειες μετριασμού που απαιτούνται για τις παλαιότερες εκδόσεις: για παράδειγμα, εάνείναι δυνατή η υποστήριξη των βελτιώσεων χωρίς να διαταραχθεί η συμβατότητα API ή εάν πρέπει νααφαιρέσετε τις παλαιότερες εκδόσεις γρήγορα και να αναγκάσετε όλους τους χρήστες / εφαρμογές-πελάτες ναμετακινηθούν στην πιο πρόσφατη έκδοση.

Αναφορές (References)Εξωτερικές Αναφορές
•CWE-1059: Incomplete Documentation•

OpenAPI InitiativeAPI10:2019 Insufficient Logging & MonitoringThreatAgentsAttackVectors

Security
Weakness

ImpactsΤεχνικές
Εξαρτώνται απόΑνιχνευσιμότητα: 1 Επιπτώσεις
την Επιχείρηση
:2Οι επιτιθέμενοι εκμεταλλεύονται Χωρίς καταγραφή και παρακολούθηση ή με Χωρίς ορατότητα σε συνεχείς
την έλλειψη καταγραφής
ανεπαρκή καταγραφή και παρακολούθηση, κακόβουλες δραστηριότητες, οισυμβάντων (logging) καιείναι σχεδόν αδύνατο να παρακολουθήσετε εισβολείς έχουν άφθονο χρόνο
παρακολούθησης (monitoring)ύποπτες δραστηριότητες και ναγια να υπονομεύσουν πλήρως
για να επιτεθούν σε συστήματα αντιδράσετε έγκαιρα.
τα συστήματα σας.
χωρίς να γίνουν αντιληπτοί.
Εξαρτώνταιαπό το APIΕκμεταλλευσιμότητα: 2Επικράτηση
(Prevalence): 3Πότε το API είναι ευάλωτο
Το API είναι ευάλωτο όταν:• Δεν παράγει κανένα αρχείο καταγραφής συμβάντων, το επίπεδο καταγραφής δεν έχει ρυθμιστεί σωστάή τα μηνύματα καταγραφής δεν περιλαμβάνουν αρκετές λεπτομέρειες.
• Η ακεραιότητα των μηνυμάτων καταγραφής δεν είναι εγγυημένη (π.χ. Log Injection).
• Τα αρχεία καταγραφής δεν παρακολουθούνται συνεχώς.
• Η υποδομή API δεν παρακολουθείται συνεχώς.

Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Τα κλειδιά πρόσβασης ενός διαχειριστικού API διέρρευσαν σε ένα δημόσια προσβάσιμο χώρο αποθήκευσης
κώδικα (αποθετήριο) (public repository). Ο κάτοχος του αποθετηρίου ειδοποιήθηκε μέσω email σχετικά με τηνπιθανή διαρροή, αλλά χρειάστηκαν περισσότερες από 48 ώρες για να αντιμετωπιστεί το συμβάν και η έκθεσητων κλειδιών πρόσβασης μπορεί να επέτρεψε την πρόσβαση σε ευαίσθητα δεδομένα. Λόγω ανεπαρκούς
καταγραφής, η εταιρεία δεν είναι σε θέση να αξιολογήσει σε ποια δεδομένα είχαν πρόσβαση κακόβουλοι
παράγοντες.

Σενάριο Επίθεσης #2
Μια πλατφόρμα κοινής χρήσης βίντεο χτυπήθηκε από μια «μεγάλης κλίμακας» επίθεση τροφοδότησης
διαπιστευτηρίων (credential stuffing). Παρά το γεγονός ότι αποτυχημένες προσπάθειες σύνδεσης
καταγράφηκαν στα αρχεία καταγραφής συμβάντων, δεν στάλθηκαν ειδοποιήσεις ασφαλείας κατά τη διάρκεια
του χρόνου της επίθεσης. Έπειτα από παράπονα χρηστών, τα αρχεία καταγραφής συμβάντων του APIαναλύθηκαν και η επίθεση εντοπίστηκε. Η εταιρεία αναγκάστηκε να αναφέρει το περιστατικό στις ρυθμιστικές
αρχές και να κάνει μια δημόσια ανακοίνωση ζητώντας από τους χρήστες να επαναφέρουν τους κωδικούς
πρόσβασής τους.

API10:2019 Insufficient Logging & MonitoringΤρόπος Πρόληψης• Καταγράψτε όλες τις αποτυχημένες προσπάθειες ελέγχου ταυτότητας, την άρνηση πρόσβασης και τασφάλματα επικύρωσης εισαγωγής (input validation errors).
• Τα αρχεία καταγραφής πρέπει να συντάσσονται χρησιμοποιώντας μια μορφή κατάλληλη για αξιοποίηση
από μια εφαρμογή διαχείρισης αρχείων καταγραφής συμβάντων (log management solution) και θαπρέπει να περιλαμβάνουν αρκετές λεπτομέρειες για τον εντοπισμό του κακόβουλου παράγοντα.
• Τα αρχεία καταγραφής θα πρέπει να αντιμετωπίζονται ως ευαίσθητα δεδομένα και η ακεραιότητά τουςθα πρέπει να είναι εγγυημένη κατά την αποθήκευση και τη μεταφορά.
• Χρησιμοποιήστε ένα σύστημα παρακολούθησης (monitoring system) για συνεχή παρακολούθηση τηςυποδομής, του δικτύου και της λειτουργίας των APIs.
• Χρησιμοποιήστε ένα σύστημα διαχείρισης πληροφοριών ασφαλείας και συμβάντων (SIEM) για νασυγκεντρώσετε και να διαχειριστείτε αρχεία καταγραφής από όλα τα στοιχεία των APIs και τωνκεντρικών υπολογιστών.
• Δημιουργήστε εξατομικευμένους πίνακες παρακολούθησης ειδοποιήσεων (dashboards). Οι πίνακες
αυτοί θα διευκολύνουν τον γρηγορότερο εντοπισμό και την διαχείριση ύποπτων δραστηριοτήτων.

Αναφορές (References)Αναφορές OWASP•OWASP Logging Cheat Sheet•OWASP Proactive Controls: Implement Logging and Intrusion Detection•

OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification
RequirementsΕξωτερικές Αναφορές
•CWE-223: Omission of Security-relevant Information•

CWE-778: Insufficient Logging

+DΕπόμενα Βήματα για Προγραμματιστές

Η εργασία δημιουργίας και συντήρησης ασφαλούς λογισμικού καθώς και η επιδιόρθωση αυτού είναι δύσκοληυπόθεση. Το ίδιο ισχύει και για τα APIs.
Πιστεύουμε ότι η εκπαίδευση και η ευαισθητοποίηση είναι βασικοί παράγοντες για τη δημιουργία ασφαλούς
λογισμικού. Τα υπόλοιπα που απαιτούνται για την επίτευξη του στόχου, εξαρτώνται από τη δημιουργία και τηχρήση επαναλαμβανόμενων διαδικασιών και τυπικών ελέγχων ασφαλείας.
Το OWASP διαθέτει πολλούς δωρεάν και ανοιχτούς πόρους για την αντιμετώπιση της ασφάλειας από την αρχήτου έργου. Επισκεφτείτε τη σελίδα OWASP Projects για την ολοκληρωμένη λίστα των διαθέσιμων έργων.
Μπορείτε να ξεκινήσετε να διαβάζετε το υλικό του OWASP Education Projectανάλογα με το επάγγελμα και το ενδιαφέρον σας. Για πρακτική μάθηση,προσθέσαμε το crAPI - Completely Ridiculous API στον οδικό μας χάρτη
(roadmap). Εν τω μεταξύ, μπορείτε να εξασκηθείτε στο WebAppSecχρησιμοποιώντας το OWASP DevSlop Pixi Module, μια ευάλωτη υπηρεσία
Εκπαίδευση
WebApp και API που έχει σκοπό να διδάξει στους χρήστες πώς να δοκιμάζουν
σύγχρονες εφαρμογές ιστού και API για ζητήματα ασφάλειας και πώς ναγράφουν πιο ασφαλή APIs στο μέλλον. Μπορείτε επίσης να παρακολουθήσετε
εκπαιδευτικές συνεδρίες του Συνεδρίου OWASP AppSec ή να εγγραφείτε στοτοπικό σας τμήμα.
Η ασφάλεια πρέπει να είναι μέρος κάθε έργου (project) από την αρχή. Ότανβρίσκεστε στο στάδιο της εξαγωγής απαιτήσεων (requirements elicitation), είναι
σημαντικό να ορίσετε τι σημαίνει "ασφαλές" για το έργο σας. Το OWASPσυνιστά να χρησιμοποιείτε το Πρότυπο Επαλήθευσης Ασφάλειας Εφαρμογών
Απαιτήσεις ΑσφαλείαςOWASP (ASVS) ως οδηγό για τον καθορισμό των απαιτήσεων ασφαλείας. Εάναναθέτετε το έργο σας σε εξωτερικούς συνεργάτες (outsourcing), εξετάστε τοΠαράρτημα Σύμβασης Ασφαλούς Λογισμικού OWASP, το οποίο θα πρέπει ναπροσαρμοστεί σύμφωνα με την τοπική νομοθεσία και τους κανονισμούς της.
Η ασφάλεια θα πρέπει να λαμβάνεται υπόψιν σε όλα τα στάδια του έργου. ΤαΣκονάκια Πρόληψης OWASP (OWASP Prevention Cheat Sheets) είναι ένα καλόσημείο εκκίνησης για καθοδήγηση σχετικά με τον τρόπο σχεδιασμού ασφάλειαςΑρχιτεκτονική Ασφαλείας
κατά τη φάση σχεδιασμού / αρχιτεκτονικής. Μεταξύ πολλών άλλων, θα βρείτε τοσκονάκι REST Security Cheat Sheet και το σκονάκι REST Assessment Cheat
Sheet.
Η υιοθέτηση Τυποποιημένων Μηχανισμών Ελέγχων Ασφαλείας (Standard
Security Controls) μειώνει τον κίνδυνο εισαγωγής αδυναμιών ασφαλείας κατάτην διάρκεια υλοποίησης της λογικής του λογισμικού σας. Παρά το γεγονός ότιπολλά σύγχρονα frameworks διαθέτουν πλέον ενσωματωμένους τυπικούς
Τυπικοί Έλεγχοι
αποτελεσματικούς ελέγχους, τα OWASP Proactive Controls σας παρέχουν μια
Ασφαλείας
καλή επισκόπηση των στοιχείων ελέγχου ασφαλείας που πρέπει νασυμπεριλάβετε στο έργο σας. Το OWASP παρέχει επίσης ορισμένες βιβλιοθήκες
και εργαλεία που μπορεί να σας φανούν πολύτιμα, όπως στοιχεία ελέγχου
επικύρωσης (validation controls).
Μπορείτε να χρησιμοποιήσετε το OWASP Software Assurance Maturity Model(SAMM) για να βελτιώσετε τη διαδικασία κατά τη δημιουργία των APIs. Πολλά
Κύκλος Ζωής Ασφαλούς
ακόμα έργα OWASP είναι διαθέσιμα για να σας βοηθήσουν σε όλες τιςΑνάπτυξης Λογισμικού
διαφορετικές φάσεις ανάπτυξης API, π.χ., το Έργο Αναθεώρησης ΚώδικαOWASP (OWASP Code Review Project).

+DSOΕπόμενα Βήματα για DevSecOps

Λόγω της σημασίας τους στις σύγχρονες αρχιτεκτονικές εφαρμογών, η δημιουργία ασφαλών API είναι ζωτικής
σημασίας. Η ασφάλεια δεν μπορεί να παραμεληθεί και θα πρέπει να αποτελεί μέρος ολόκληρου του κύκλου
ζωής της ανάπτυξης των APIs. Η σάρωση (scanning) και οι ετήσιες δοκιμές διείσδυσης (penetration tests) δενείναι πλέον αρκετές.
Οι DevSecOps θα πρέπει να συμμετάσχουν στην προσπάθεια ανάπτυξης, διευκολύνοντας τις συνεχείς δοκιμές
ασφαλείας σε ολόκληρο τον κύκλο ζωής ανάπτυξης λογισμικού. Στόχος τους είναι να ενισχύσουν τον αγωγό
ανάπτυξης (development pipeline) με αυτοματισμό ασφαλείας (security automation), χωρίς να επηρεάζουν τηνταχύτητα ανάπτυξης.
Για περισσότερες πληροφορίες, μπορείτε να ελέγχετε συχνά το DevSecOps Manifesto για να μείνετε
ενημερωμένοι.

Οι προτεραιότητες δοκιμών (testing priorities) προέρχονται από ένα μοντέλο
απειλής (threat model). Εάν δεν έχετε μοντέλο απειλής, εξετάστε το ενδεχόμενο
να χρησιμοποιήσετε το Πρότυπο Επαλήθευσης Ασφάλειας Εφαρμογών OWASPΚατανοήστε το Μοντέλο(OWASP Application Security Verification Standard) (ASVS) και τον Οδηγό
Απειλής (Threat Model)Δοκιμής OWASP (OWASP Testing Guide). Η συμμετοχή της ομάδας ανάπτυξης
μπορεί να βοηθήσει τους προγραμματιστές να γίνουν περισσότερο ενήμεροι γιατην ασφάλεια.

Κατανoήστε το SDLC

Γίνετε μέλος της ομάδας ανάπτυξης για να κατανοήσετε καλύτερα τον Κύκλο
Ζωής Ανάπτυξης Λογισμικού. Η συνεισφορά σας στις συνεχείς δοκιμές
ασφαλείας θα πρέπει να είναι συμβατή με τα άτομα, τις διαδικασίες και ταεργαλεία που έχουν θεσπιστεί. Να επισημανθεί ότι πρέπει να συμφωνούν όλοι μετη διαδικασία, ώστε να μην υπάρχουν περιττές τριβές ή αντιστάσεις.

Στρατηγικές TestingΚαθώς η εργασία σας δεν πρέπει να επηρεάζει την ταχύτητα ανάπτυξης του API,θα πρέπει να επιλέξετε με σύνεση την καλύτερη (απλή, ταχύτερη, πιο ακριβή)τεχνική για να επαληθεύσετε τις απαιτήσεις ασφαλείας. Το Γνωσιακό Πλαίσιο
Ασφαλείας OWASP (ΟWASP Security Knowledge Framework) και το Πρότυπο
Επαλήθευσης Ασφάλειας Εφαρμογών OWASP (OWASP Application Security
Verification Standard) μπορούν να αποτελέσουν εξαιρετικές πηγές λειτουργικών
και μη λειτουργικών απαιτήσεων ασφαλείας. Υπάρχουν άλλες εξαιρετικές πηγές
για Έργα and Εργαλεία παρόμοιες με αυτήν που προσφέρει η Kοινότητα
DevSecOps.

Είστε η γέφυρα μεταξύ προγραμματιστών και ομάδων λειτουργιών (operation
teams). Για να πετύχετε κάλυψη (coverage), δεν πρέπει να εστιάσετε μόνο στηΕπίτευξη Κάλυψης
λειτουργικότητα, αλλά και στην ενορχήστρωση. Εργαστείτε από την αρχή κοντά
(Coverage) και ακριβείας
στις ομάδες ανάπτυξης και λειτουργίας, ώστε να βελτιστοποιήσετε τον χρόνο και(Accuracy)την προσπάθειά σας. Θα πρέπει να στοχεύσετε σε μια κατάσταση όπου η βασική
ασφάλεια επαληθεύεται συνεχώς.

Επικοινωνήστε μεσαφήνεια τα ευρήματα

Συνεισφέρετε αξία με λιγότερη ή καθόλου τριβή. Παραδώστε τα ευρήματα σαςέγκαιρα, μέσα στα εργαλεία που χρησιμοποιούν οι ομάδες ανάπτυξης (όχιαρχεία PDF). Γίνετε μέλος της ομάδας ανάπτυξης για να αντιμετωπίσετε ταευρήματα. Εκμεταλλευτείτε την ευκαιρία για να τους εκπαιδεύσετε,
περιγράφοντας ξεκάθαρα την αδυναμία και πώς μπορεί να γίνει κατάχρηση της,συμπεριλαμβάνοντας ένα σενάριο επίθεσης για να γίνετε κατανοητοί.

+DATΜεθοδολογία και Δεδομένα

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

Μεθοδολογία και Δεδομένα
Στην πρώτη φάση συλλέχθηκαν, εξετάστηκαν και κατηγοριοποιήθηκαν δημόσια δεδομένα σχετικά μεσυμβάντα ασφαλείας API από μια ομάδα ειδικών σε θέματα ασφαλείας. Τα δεδομένα αυτά συλλέχθηκαν απόπλατφόρμες επιβράβευσης σφαλμάτων (bug bounty platforms) και βάσεις δεδομένων ευπάθειας, τα οποία
καταχωρήθηκαν στο χρονικό διάστημα ενός έτους και χρησιμοποιήθηκαν για στατιστικούς σκοπούς.
Στην επόμενη φάση οι επαγγελματίες ασφαλείας με εμπειρία σε δοκιμές διείσδυσης (penetration testing)κλήθηκαν να συντάξουν τη δική τους λίστα Top 10.
Η OWASP Risk Rating Methodology χρησιμοποιήθηκε για την εκτέλεση της Ανάλυσης Κινδύνου. Οιβαθμολογίες συζητήθηκαν και αναθεωρήθηκαν μεταξύ των επαγγελματιών ασφαλείας. Για περισσότερες
πληροφορίες σχετικά με αυτά τα θέματα ανατρέξτε στην ενότητα Κίνδυνοι Ασφαλείας API.
Το πρώτο προσχέδιο του OWASP API Security Top 10 2019 προέκυψε από συναίνεση των στατιστικών
αποτελεσμάτων της πρώτης φάσης και από τις λίστες που προετοίμασαν οι επαγγελματίες ασφαλείας. Τοπροσχέδιο υποβλήθηκε στη συνέχεια για εκτίμηση και αξιολόγηση από άλλη ομάδα επαγγελματιών ασφαλείας,με σχετική εμπειρία στους τομείς ασφαλείας API.
Το OWASP API Security Top 10 2019 παρουσιάστηκε για πρώτη φορά στην εκδήλωση OWASP Global
AppSec Tel Aviv (Μάιος 2019). Από τότε είναι διαθέσιμο στο GitHub για δημόσια συζήτηση και συνεισφορές.
Η λίστα των συντελεστών είναι διαθέσιμη στην ενότητα Ευχαριστίες.

+ACKΕυχαριστίες

Ευχαριστίες προς τους Συντελεστές
Θα θέλαμε να ευχαριστήσουμε τους ακόλουθους συντελεστές που συνεισέφεραν δημόσια στο GitHub ή μεάλλα μέσα:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

007divyachawla
Abid Khan
Adam Fisher
anotherikbkimminichcaseysoftware
Chris Westphal
dsopasDSotnikov
emilvaErezYalon
flascelles
Guillaume Benats
IgorSasovets
Inonshk
JonnySchnittger
jmanicojmdx
Keith Casey
kozmicLauraRosePorter
Matthieu Estradenathanawmk
PauloASilva
pentagramz
philippederyckpleothaud
r00ter
Raj kumar
Sagar Popat
Stephen Gates
thomaskonrad
xycloops123