Τι Είναι το OWASP Top 10: Επισκόπηση

Το OWASP Top 10 είναι η πιο γνωστή λίστα με τους δέκα πιο κρίσιμους κινδύνους ασφαλείας για διαδικτυακές εφαρμογές (web applications). Λειτουργεί ως κοινή «γλώσσα» ανάμεσα σε προγραμματιστές, ελεγκτές διείσδυσης (penetration testers) και ομάδες άμυνας. Σε αυτό το εισαγωγικό εργαστήριο εξηγούμε τι είναι, γιατί έχει σημασία, ρίχνουμε μια ματιά και στις δέκα κατηγορίες, και τις χαρτογραφούμε σε πραγματικά bugs μέσα σε ένα απομονωμένο lab — πάντα με έμφαση στην ανίχνευση και την άμυνα.

1. Γιατί έχει σημασία το OWASP Top 10

Το OWASP (Open Worldwide Application Security Project) είναι ένας μη κερδοσκοπικός οργανισμός που παράγει δωρεάν, ανοιχτό υλικό για την ασφάλεια λογισμικού. Το πιο διάσημο παραδοτέο του είναι το OWASP Top 10: μια λίστα που ανανεώνεται περιοδικά (η ευρέως χρησιμοποιούμενη έκδοση είναι του 2021) και συνοψίζει τις δέκα σημαντικότερες κατηγορίες κινδύνου για web εφαρμογές, με βάση δεδομένα από χιλιάδες πραγματικές εφαρμογές και αναφορές ασφαλείας.

Γιατί το χρειάζεται ένας αρχάριος στην ηθική άσκηση διείσδυσης (ethical hacking); Επειδή είναι ο ταχύτερος τρόπος να μάθεις πού «σπάνε» συνήθως οι εφαρμογές. Αντί να ψάχνεις στα τυφλά, ξέρεις από την αρχή ότι η συντριπτική πλειονότητα των πραγματικών ευπαθειών (vulnerabilities) πέφτει σε λίγες, επαναλαμβανόμενες κατηγορίες. Η ίδια λίστα καθοδηγεί και τις δύο πλευρές: ο ελεγκτής την χρησιμοποιεί ως checklist για το τι να δοκιμάσει, ενώ η ομάδα άμυνας (blue team) την χρησιμοποιεί ως προτεραιότητα για το τι να θωρακίσει πρώτο.

Το OWASP Top 10 εμφανίζεται παντού: σε προδιαγραφές ασφαλών εφαρμογών, σε συμβόλαια penetration testing, σε ελέγχους συμμόρφωσης (compliance) και σε πλαίσια όπως το PCI DSS. Το να το κατανοείς είναι, με απλά λόγια, το θεμέλιο του application security.

2. Βασικές έννοιες: οι δέκα κατηγορίες

Η λίστα δεν είναι κατάλογος συγκεκριμένων bugs, αλλά κατηγορίες κινδύνου (risk categories). Κάθε κατηγορία μαζεύει πολλές συγγενείς ευπάθειες κάτω από μία «ομπρέλα». Ας τις δούμε συνοπτικά (έκδοση 2021):

1. A01 — Broken Access Control (Ελαττωματικός έλεγχος πρόσβασης): χρήστες αποκτούν πρόσβαση σε δεδομένα ή ενέργειες που δεν τους ανήκουν, π.χ. αλλάζοντας ένα ID στο URL (IDOR).
2. A02 — Cryptographic Failures (Αστοχίες κρυπτογραφίας): ευαίσθητα δεδομένα εκτεθειμένα λόγω απούσας ή αδύναμης κρυπτογράφησης (π.χ. κωδικοί σε plaintext, HTTP αντί για HTTPS).
3. A03 — Injection (Ένεση): μη έμπιστη είσοδος «σπάει» ένα query ή μια εντολή, όπως στο SQL injection ή στο command injection.
4. A04 — Insecure Design (Μη ασφαλής σχεδίαση): ελαττώματα στην ίδια τη λογική/αρχιτεκτονική, όχι απλώς στην υλοποίηση.
5. A05 — Security Misconfiguration (Λανθασμένη ρύθμιση ασφαλείας): default κωδικοί, περιττά ενεργά features, ελλιπείς HTTP headers, verbose μηνύματα σφάλματος.
6. A06 — Vulnerable and Outdated Components (Ευάλωτα & ξεπερασμένα components): βιβλιοθήκες ή frameworks με γνωστές ευπάθειες που δεν έχουν ενημερωθεί.
7. A07 — Identification and Authentication Failures (Αστοχίες ταυτοποίησης & αυθεντικοποίησης): αδύναμοι κωδικοί, ελλιπής προστασία από brute force, κακή διαχείριση sessions.
8. A08 — Software and Data Integrity Failures (Αστοχίες ακεραιότητας): εμπιστοσύνη σε μη επαληθευμένο κώδικα/updates, ανασφαλής deserialization, παραβιασμένα pipelines (supply chain).
9. A09 — Security Logging and Monitoring Failures (Αστοχίες καταγραφής & παρακολούθησης): επιθέσεις που περνούν απαρατήρητες επειδή δεν καταγράφεται ή δεν ελέγχεται τίποτα.
10. A10 — Server-Side Request Forgery / SSRF: η εφαρμογή αναγκάζεται να κάνει αιτήματα σε εσωτερικούς πόρους που ο επιτιθέμενος δεν θα έπρεπε να φτάνει.

Δύο σημεία-κλειδιά για αρχάριους: πρώτον, η σειρά έχει νόημα — το A01 βρίσκεται στην κορυφή επειδή εμφανίζεται συχνότερα και με μεγαλύτερο αντίκτυπο. Δεύτερον, οι κατηγορίες συχνά συνδυάζονται: ένα πραγματικό περιστατικό μπορεί να ξεκινά από A05 (misconfiguration) και να καταλήγει σε A01 (πρόσβαση σε ξένα δεδομένα).

3. Πρακτικό κομμάτι στο lab

Η θεωρία γίνεται σαφής μόνο όταν δεις τις κατηγορίες σε πραγματικό κώδικα. Θα χρησιμοποιήσουμε το OWASP Juice Shop — μια σκόπιμα ευάλωτη εφαρμογή, φτιαγμένη από το ίδιο το OWASP για εκπαίδευση — μέσα στο απομονωμένο lab μας στη διεύθυνση 10.10.10.10.

Βήμα 1 — Στήνουμε το ευάλωτο περιβάλλον

Ξεκινάμε το Juice Shop ως container και επιβεβαιώνουμε ότι απαντά. Όλα γίνονται τοπικά, χωρίς καμία σύνδεση με το internet ή τρίτα δίκτυα.

kali@lab:~/eh-lab$ sudo docker run -d --name juice -p 3000:3000 bkimminich/juice-shop

Η εφαρμογή τρέχει τώρα στη θύρα 3000 και επιστρέφει 200. Έχουμε έναν ασφαλή «στόχο εξάσκησης» πάνω στον οποίο θα δούμε τρεις διαφορετικές κατηγορίες του Top 10.

Βήμα 2 — A01: Broken Access Control (IDOR)

Το πιο συχνό εύρημα της λίστας. Πολλά API επιστρέφουν αντικείμενα με βάση ένα αριθμητικό id χωρίς να ελέγχουν αν ο συγκεκριμένος χρήστης δικαιούται να το δει. Αλλάζοντας απλώς το ID στο URL, βλέπουμε δεδομένα άλλου χρήστη — αυτό λέγεται IDOR (Insecure Direct Object Reference).

kali@lab:~/eh-lab$ curl -s http://10.10.10.10:3000/api/Users/1 | jq

Χωρίς κανέναν έλεγχο δικαιωμάτων, το endpoint μας έδωσε τα στοιχεία του χρήστη 1 (admin) και, με μια απλή αλλαγή σε /2, ενός δεύτερου χρήστη. Η άμυνα εδώ είναι απλή στην αρχή αλλά συχνά ξεχνιέται: κάθε αίτημα πρέπει να επαληθεύει ότι ο τρέχων χρήστης δικαιούται το συγκεκριμένο αντικείμενο (server-side authorization).

Βήμα 3 — A03: Injection (SQL injection)

Στη δεύτερη κατηγορία, στέλνουμε κακόβουλη είσοδο σε ένα πεδίο σύνδεσης. Το κλασικό payload ' OR 1=1-- «σπάει» το SQL query πίσω από τη φόρμα login, κάνοντας τη συνθήκη πάντα αληθή και παρακάμπτοντας τον έλεγχο κωδικού.

kali@lab:~/eh-lab$ curl -s -X POST http://10.10.10.10:3000/rest/user/login \
     -H "Content-Type: application/json" -d @login.json

Ο server επέστρεψε ένα έγκυρο authentication token χωρίς σωστό κωδικό. Το πρόβλημα δεν είναι ο κωδικός, αλλά ότι η εφαρμογή χτίζει το query ενώνοντας κείμενο με την είσοδο του χρήστη. Η άμυνα είναι τα parameterized queries (prepared statements), που κρατούν τα δεδομένα ξεχωριστά από την εντολή SQL.

Βήμα 4 — Χαρτογράφηση ευρημάτων σε κατηγορίες

Στην πράξη, ένας ελεγκτής δεν κοιτά μία ευπάθεια τη φορά· τρέχει έναν σαρωτή και μετά χαρτογραφεί κάθε εύρημα στην αντίστοιχη κατηγορία του Top 10. Ας δούμε πώς μοιάζει αυτό με έναν απλό web scanner.

kali@lab:~/eh-lab$ nikto -h http://10.10.10.10:3000 -maxtime 60s

Παρατήρησε πώς τα ευρήματα δεν μένουν «ξεκρέμαστα»: οι ελλείποντες HTTP headers και η διαρροή έκδοσης πέφτουν στο A05, το εκτεθειμένο directory listing και το ανοιχτό /api/Users στο A01/A07. Αυτή η αντιστοίχιση είναι που μετατρέπει μια λίστα σφαλμάτων σε χρήσιμη, ιεραρχημένη αναφορά — και δίνει στην ομάδα άμυνας σαφή σειρά προτεραιότητας για τις διορθώσεις.

4. Το εργαστηριακό περιβάλλον

Κάθε εντολή αυτού του άρθρου εκτελέστηκε σε ένα πλήρως απομονωμένο lab, χωρίς καμία σύνδεση με πραγματικά ή τρίτα συστήματα. Η προτεινόμενη διάταξη:

• Επιτιθέμενος: μια εικονική μηχανή Kali Linux με προεγκατεστημένα curl, jq και nikto.
• Στόχος: το OWASP Juice Shop (ή το DVWA / bWAPP) ως τοπικό container στο 10.10.10.10 — σκόπιμα ευάλωτες εφαρμογές, φτιαγμένες αποκλειστικά για εξάσκηση.
• Δικτύωση: όλες οι VMs σε Host-Only ή Internal Network adapter στο VirtualBox/VMware — ποτέ σε bridged mode που θα εξέθετε τις δοκιμές στο πραγματικό δίκτυο.

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

5. Ηθικό & νομικό πλαίσιο

Οι τεχνικές αυτού του άρθρου είναι νόμιμες μόνο σε εφαρμογές που σου ανήκουν ή για τις οποίες έχεις ρητή, γραπτή εξουσιοδότηση. Η δοκιμή SQL injection ή η εκμετάλλευση IDOR σε ξένη εφαρμογή — ακόμη κι «από περιέργεια» — μπορεί να αποτελεί ποινικό αδίκημα, ανεξάρτητα από το αν προκληθεί ζημιά.

• Εξουσιοδότηση πρώτα: πάντα με καθορισμένο scope και γραπτή άδεια (rules of engagement) πριν αγγίξεις οτιδήποτε εκτός του lab σου.
• Μόνο εντός scope: δοκίμασε αποκλειστικά τις εφαρμογές και τα endpoints που ορίζει η σύμβαση.
• Οπτική άμυνας: ο σκοπός του OWASP Top 10 είναι να χτίζεις ασφαλέστερο λογισμικό. Οι ίδιες γνώσεις βοηθούν την blue team να ανιχνεύει επιθέσεις (μέσω logging & monitoring — A09) και να κλείνει τα κενά πριν τα βρει κάποιος άλλος.

Ο στόχος του ethical hacking δεν είναι η επίθεση, αλλά η κατανόηση και η θωράκιση. Το OWASP Top 10 είναι ένας χάρτης κινδύνων — η δεοντολογική του χρήση είναι δική σου ευθύνη.

6. Βασικά συμπεράσματα

• Το OWASP Top 10 συνοψίζει τους δέκα πιο κρίσιμους κινδύνους για web εφαρμογές και αποτελεί κοινή γλώσσα ανάμεσα σε developers, testers και ομάδες άμυνας.
• Πρόκειται για κατηγορίες κινδύνου, όχι μεμονωμένα bugs· η σειρά (A01→A10) αντικατοπτρίζει συχνότητα και αντίκτυπο.
• Το A01 (Broken Access Control) είναι το πιο συχνό — ένα απλό IDOR αρκεί για να το δεις στην πράξη.
• Το A03 (Injection) προλαμβάνεται με parameterized queries· η άμυνα ξεκινά από τον σχεδιασμό, όχι από τα patches.
• Η αξία της λίστας φαίνεται στη χαρτογράφηση: κάθε εύρημα ενός scanner αποκτά νόημα και προτεραιότητα όταν δεθεί με μια κατηγορία.
• Δούλεψε μόνο σε απομονωμένο lab ή με γραπτή εξουσιοδότηση — η νομιμότητα και η δεοντολογία προηγούνται πάντα.

Από τη θεωρία στην πράξη. Η Audax Cybersecurity προσφέρει επαγγελματικές υπηρεσίες offensive security — penetration testing & offensive validation — ενώ για όσους ξεκινούν το ταξίδι τους στο ethical hacking, το #1 ελληνικό βιβλίο «Ethical Hacking — Η Κρυφή Γνώση» είναι ο ιδανικός οδηγός.