API & JWT Attack Chain: από το SQL Injection στο forged admin token με ffuf, arjun, sqlmap και jwt_tool

Εισαγωγή: γιατί τα APIs είναι το νέο κύριο πεδίο επίθεσης

Την τελευταία δεκαετία, η βαρύτητα της επιφάνειας επίθεσης μετατοπίστηκε σιωπηλά αλλά αποφασιστικά. Οι σύγχρονες εφαρμογές δεν είναι πια μονολιθικές ιστοσελίδες που σερβίρουν HTML· είναι συλλογές από APIs — REST, GraphQL, gRPC — που μιλούν μεταξύ τους και με mobile apps, single-page frontends, integrations τρίτων και microservices. Το «κέντρο βάρους» της λογικής μιας εφαρμογής βρίσκεται σήμερα πίσω από ένα API endpoint, όχι μέσα σε μια φόρμα HTML.

TL;DR (EN): An API/JWT attack chain in an isolated lab: ffuf, arjun, sqlmap and jwt_tool, from route and parameter discovery to a SQL injection that leaks the JWT secret, then a weak-secret crack and alg:none bypass to forge an admin token — with the defenses that close each gap.

Αυτή η μετατόπιση δημιούργησε ένα πρόβλημα ορατότητας. Ένα API δεν έχει «σελίδες» να δει κανείς με τον browser. Δεν έχει ορατά links να ακολουθήσει ένας crawler. Οι developers ξέρουν τι endpoints υπάρχουν· ο υπόλοιπος κόσμος — συμπεριλαμβανομένων των αμυντικών ομάδων — συχνά όχι. Και ακριβώς επειδή τα APIs είναι «αόρατα» στο γυμνό μάτι, συγκεντρώνουν μια ολόκληρη οικογένεια αδυναμιών που το OWASP κωδικοποίησε στο OWASP API Security Top 10: broken object level authorization, broken authentication, excessive data exposure, και — το πιο ύπουλο απ’ όλα — endpoints και παράμετροι που κανείς δεν θυμάται ότι υπάρχουν.

Πάνω σε αυτό το τοπίο έρχεται να προστεθεί το JWT (JSON Web Token), το de facto πρότυπο για stateless authentication σε APIs. Το JWT είναι κομψό: ο server υπογράφει ένα token με τα claims του χρήστη (ποιος είναι, τι ρόλο έχει, πότε λήγει), και ο client το παρουσιάζει σε κάθε request. Ο server απλώς επαληθεύει την υπογραφή — δεν χρειάζεται session state. Όμως αυτή η κομψότητα κρύβει έναν κίνδυνο: αν η επαλήθευση της υπογραφής είναι λανθασμένη, ολόκληρο το μοντέλο authentication καταρρέει. Και οι δύο κλασικές αστοχίες — το αδύναμο signing secret και η αποδοχή του alg:none — εξακολουθούν να εμφανίζονται σε πραγματικά production APIs, δεκαετία μετά την πρώτη τους δημοσιοποίηση.

Σε αυτό το flagship άρθρο των Audax Labs στήνουμε ακριβώς αυτή την ιστορία από άκρη σε άκρη, με τέσσερα εργαλεία που κάθε σοβαρός επαγγελματίας offensive security οφείλει να γνωρίζει για τον έλεγχο APIs:

1. ffuf — για ταχύτατη ανακάλυψη των endpoints ενός API που δεν διαφημίζει τον εαυτό του.
2. arjun — για τον εντοπισμό κρυφών, μη τεκμηριωμένων parameters που δεν φαίνονται πουθενά.
3. sqlmap — για την εκμετάλλευση μιας SQL injection σε ένα από αυτά τα parameters, με στόχο να διαρρεύσουμε τον πίνακα χρηστών και το ίδιο το signing secret των JWT.
4. jwt_tool — για την επίθεση στο JWT authentication: σπάσιμο του αδύναμου HMAC secret και εκμετάλλευση του alg:none, ώστε να πλαστογραφήσουμε ένα admin token.

Η αφήγηση ακολουθεί πέντε κινήσεις: discover -> enumerate -> inject -> forge -> access. Και όπως σε κάθε άρθρο των Audax Labs, δεν αρκούμαστε στο «τι εντολή τρέξαμε»: εξηγούμε τι είναι το κάθε εργαλείο, ποιες είναι οι σημαντικότερες παράμετροί του, ποια εντολή δώσαμε και τι πραγματικά επέστρεψε — με αποστειρωμένα, αναγνώσιμα screenshots από το ίδιο το εργαστήριο. Κλείνουμε με αντιστοίχιση σε MITRE ATT&CK και με μια σκληρή, πρακτική ενότητα άμυνας: πώς σταματάτε κάθε ένα από αυτά τα βήματα στο δικό σας περιβάλλον.

Το σενάριο και το εργαστήριο

Ο στόχος μας, το «Helios Retail API», είναι το backend ενός μικρού ηλεκτρονικού καταστήματος. Δεν έχει καθόλου frontend — είναι ένα καθαρό JSON API, όπως ακριβώς αυτά που τρέχουν πίσω από χιλιάδες mobile apps και SPAs. Κάτω από την επιφάνεια, έχει τέσσερα σκόπιμα φυτεμένα λάθη που, μεμονωμένα, μοιάζουν «διαχειρίσιμα», αλλά αλυσιδωτά δίνουν πλήρη πρόσβαση διαχειριστή:

• Ανακαλύψιμα endpoints χωρίς τεκμηρίωση: το /api επιστρέφει μια λίστα, αλλά υπάρχουν διαδρομές (/api/admin, /api/orders, /api/profile) που απαντούν με 401/403 — δηλαδή υπάρχουν και απλώς προστατεύονται.
• Κρυφό, μη τεκμηριωμένο parameter: το /api/products δέχεται ένα φίλτρο ?category= που δεν αναφέρεται πουθενά στην τεκμηρίωση.
• SQL injection με string concatenation: το category περνάει κατευθείαν, χωρίς parameterisation, μέσα σε ένα SQL query — το κλασικό, «σχολικό» λάθος που όμως συνεχίζει να υπάρχει.
• Ελαττωματικό JWT authentication: ο server (α) υπογράφει τα tokens με ένα αδύναμο, λεξικογραφικά μαντεύσιμο HMAC secret και (β) εμπιστεύεται το πεδίο alg που ελέγχει ο επιτιθέμενος, αποδεχόμενος ακόμα και alg:none (token χωρίς υπογραφή).

Τοπολογία

Ο στόχος τρέχει ως μια αυτόνομη εφαρμογή Python (Flask + SQLite), δεσμευμένη σε απομονωμένη διεύθυνση loopback (127.0.0.1:8899). Η μηχανή επίθεσης είναι ο ίδιος host, με ταυτότητα χειριστή απόλυτα ουδέτερη (kali@lab). Δεν υπάρχει καμία γέφυρα προς LAN ή Internet, καμία δημοσιευμένη θύρα.

Ειλικρινής διευκρίνιση για το Docker και τα δίκτυα. Η αρχική πρόθεση ήταν ο στόχος να τρέξει σε Docker, σε ένα internal: true bridge χωρίς δημοσιευμένες θύρες. Στο συγκεκριμένο περιβάλλον ο Docker daemon δεν ήταν διαθέσιμος (ήταν ανενεργός και δεν υπήρχε δικαίωμα εκκίνησής του χωρίς sudo). Ακολουθήσαμε λοιπόν την ισοδύναμη εναλλακτική: δέσμευση του στόχου σε απομονωμένη διεύθυνση loopback. Το αποτέλεσμα είναι ισοδύναμο ως προς την απομόνωση — τίποτα δεν εκτίθεται εκτός host — και το δηλώνουμε ρητά. Στα screenshots οι διευθύνσεις παρουσιάζονται ως ένα καθαρό εργαστηριακό segment (π.χ. 10.10.10.30 για τον στόχο) για ευανάγνωστη αφήγηση, ενώ πραγματικά ο server άκουγε στο 127.0.0.1:8899.

Πριν προχωρήσουμε βήμα-βήμα, ας δούμε ολόκληρη την αλυσίδα σε ένα διάγραμμα:

Οι εκδόσεις των εργαλείων που χρησιμοποιήσαμε ήταν: ffuf 2.1.0, arjun 2.2.7, sqlmap 1.10.7 και jwt_tool 2.3.0, με Python 3.12 και Flask 3.1 για τον στόχο. Όλα τρέχουν τοπικά, μέσα σε ένα Python virtual environment, χωρίς εγκατάσταση σε system paths και χωρίς root.

Εργαλείο 1 — ffuf: ανακάλυψη των endpoints ενός «αόρατου» API

Τι είναι και πού ταιριάζει

Το ffuf (Fuzz Faster U Fool) είναι ένας ταχύτατος web fuzzer γραμμένος σε Go. Η βασική του ιδέα είναι απλή αλλά ισχυρή: βάζεις τη λέξη-κλειδί FUZZ οπουδήποτε μέσα σε ένα request — στο URL, σε μια παράμετρο, σε ένα header, στο σώμα — και το ffuf αντικαθιστά διαδοχικά κάθε γραμμή ενός wordlist, αναφέροντας πώς αντιδρά ο server. Με φίλτρα και matchers απομονώνεις ακριβώς τις απαντήσεις που σε ενδιαφέρουν.

Πού ταιριάζει: στην αρχή κάθε ελέγχου API. Ένα API δεν σου «δείχνει» τι endpoints έχει. Το ffuf μετατρέπει το «βλέπω μόνο ένα /api που λέει λίγα» σε «ξέρω ότι υπάρχουν /api/products, /api/orders, /api/profile, /api/admin και /api/login, και ξέρω ποια είναι δημόσια, ποια θέλουν authentication και ποια δέχονται μόνο POST».

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

ffuf -w wordlists/api-routes.txt \
  -u http://10.10.10.30/api/FUZZ \
  -mc 200,401,403,405 -t 20

Το «κλειδί» εδώ είναι η επιλογή των status codes που κάνουμε match. Δεν ψάχνουμε μόνο 200. Σε ένα API, ένα 401 Unauthorized ή ένα 403 Forbidden είναι εξίσου πολύτιμο: μας λέει ότι το endpoint υπάρχει και απλώς απαιτεί authentication. Ένα 405 Method Not Allowed μας αποκαλύπτει ότι το endpoint υπάρχει αλλά περιμένει άλλο HTTP method (εδώ, το /api/login δέχεται μόνο POST).

Το αποτέλεσμα ήταν καθαρός χάρτης: /api/health και /api/products επιστρέφουν 200 (δημόσια), τα /api/orders, /api/profile και /api/admin επιστρέφουν 401 (υπάρχουν, θέλουν token), και το /api/login επιστρέφει 405 (POST-only). Μέσα σε δευτερόλεπτα, ένα API «χωρίς σελίδες» απέκτησε πλήρη τοπολογία. Το /api/admin ξεχώρισε αμέσως ως ο τελικός μας στόχος — και το /api/products, ως το πιο υποσχόμενο σημείο εισόδου, αφού είναι δημόσιο και δέχεται input.

Εργαλείο 2 — arjun: εντοπισμός του κρυφού parameter

Τι είναι και πού ταιριάζει

Το arjun είναι ένας εξειδικευμένος HTTP parameter discovery scanner, γραμμένος σε Python. Λύνει ένα πρόβλημα που το ffuf, στην κλασική του χρήση, δεν λύνει: το να βρει παραμέτρους που ένα endpoint δέχεται αλλά δεν διαφημίζει. Πολλά endpoints κρύβουν λειτουργικότητα πίσω από parameters που δεν εμφανίζονται πουθενά — φίλτρα, debug flags, «κρυφές» επιλογές που ξέχασε ο developer. Το arjun στέλνει μαζικά υποψήφια ονόματα parameters και παρακολουθεί αλλαγές στην απάντηση (μήκος σώματος, status code, λέξεις, reflections) για να εντοπίσει ποια «μετράνε».

Πού ταιριάζει: αμέσως μετά την ανακάλυψη των endpoints. Ξέρουμε ότι το /api/products είναι δημόσιο και δέχεται input — αλλά τι input; Το arjun μας το λέει.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

arjun -u http://10.10.10.30/api/products -m GET

Το arjun πρώτα «σταθεροποιεί» το baseline (στέλνει αβλαβή requests για να καταλάβει πώς μοιάζει μια κανονική απάντηση), κατόπιν δοκιμάζει τα υποψήφια parameters σε chunks, και τέλος επιβεβαιώνει τα ευρήματα.

Το αποτέλεσμα ήταν μονοσήμαντο: parameter detected: category, based on: body length. Το arjun εντόπισε ότι, όταν στέλνουμε ?category=<κάτι>, το μήκος του σώματος της απάντησης αλλάζει — γιατί το API φιλτράρει τα προϊόντα. Αυτό το category δεν αναφέρεται πουθενά στο /api. Είναι ένα κρυφό σημείο εισόδου — και, όπως θα δούμε, το πιο επικίνδυνο σημείο ολόκληρου του API.

Το δίδαγμα εδώ είναι θεμελιώδες για τον έλεγχο APIs: η επιφάνεια επίθεσης δεν είναι μόνο τα endpoints· είναι και οι παράμετροι. Ένα endpoint που φαίνεται «read-only» μπορεί να κρύβει ένα injectable parameter που ανοίγει διάπλατα την πόρτα.

Εργαλείο 3 — sqlmap: από το κρυφό parameter στη διαρροή του JWT secret

Τι είναι και πού ταιριάζει

Το sqlmap είναι το κορυφαίο open-source εργαλείο για την αυτόματη ανίχνευση και εκμετάλλευση SQL injection. Δουλειά του είναι να δοκιμάσει μεθοδικά ένα σημείο εισόδου με δεκάδες τεχνικές (boolean-based, error-based, UNION-based, time-based, stacked queries), να επιβεβαιώσει την ευπάθεια, να ταυτοποιήσει το DBMS, και μετά — αν του το ζητήσεις — να εξάγει δεδομένα: βάσεις, πίνακες, στήλες, εγγραφές.

Πού ταιριάζει: πάνω στο category που μας έδωσε το arjun. Ο συνδυασμός είναι κλασικός και θανατηφόρος — το arjun βρίσκει πού να χτυπήσεις, το sqlmap αποδεικνύει τι μπορείς να αποσπάσεις.

Σημαντικές παράμετροι / flags

Ανίχνευση της ευπάθειας

sqlmap -u 'http://10.10.10.30/api/products?category=peripherals' \
  -p category --batch --dbms sqlite --technique=U

Το sqlmap δούλεψε μεθοδικά: με την τεχνική ORDER BY βρήκε ότι το query έχει 3 στήλες, δοκίμασε UNION payloads, και επιβεβαίωσε ότι το category είναι injectable μέσω Generic UNION query. Ταυτοποίησε το backend ως SQLite.

Το payload που κατασκεύασε το sqlmap είναι διδακτικό: category=peripherals' UNION ALL SELECT NULL,NULL,CHAR(...)-- LODK. Χρησιμοποιεί CHAR() για να αποφύγει τα quotes και ένα τυχαίο marker (LODK) για να αναγνωρίζει τα δικά του reflections μέσα στην απάντηση.

Εξαγωγή των πινάκων: users + app_secrets

Έχοντας επιβεβαιωμένη injection, ζητήσαμε το «λαβράκι» — τους δύο πίνακες που μας ενδιαφέρουν:

sqlmap -u 'http://10.10.10.30/api/products?category=peripherals' \
  -p category --batch --dbms sqlite --dump -T users,app_secrets

Το αποτέλεσμα κλείνει την πρώτη μισή αλυσίδα με εκκωφαντικό τρόπο. Ο πίνακας users αποκάλυψε τρεις λογαριασμούς, μαζί με τον διαχειριστή helios_admin και τον ρόλο του. Αλλά το πραγματικά καταστροφικό εύρημα ήταν ο πίνακας app_secrets:

Μόλις διαρρεύσαμε το ίδιο το κλειδί με το οποίο ο server υπογράφει όλα τα JWT. Αυτή η αποθήκευση secrets μέσα στη βάση δεδομένων της εφαρμογής — προσβάσιμη μέσω της ίδιας injection — είναι ένα δεύτερο, ανεξάρτητο λάθος που πολλαπλασιάζει τον αντίκτυπο του πρώτου. Και είναι εντυπωσιακά συχνό στην πράξη: secrets σε πίνακες config, σε .env που καταλήγουν σε στήλες, σε «temporary» θέσεις που δεν καθαρίστηκαν ποτέ.

Εργαλείο 4 — jwt_tool: σπάσιμο, alg:none και forged admin token

Τι είναι και πού ταιριάζει

Το jwt_tool είναι το «ελβετικό μαχαίρι» για επιθέσεις σε JSON Web Tokens. Αποκωδικοποιεί tokens, ελέγχει τα claims, δοκιμάζει γνωστές ευπάθειες (alg:none, key confusion RS256->HS256, injection σε kid/jku/x5u), κάνει brute-force/dictionary crack αδύναμων HMAC secrets, και — κρίσιμο για εμάς — πλαστογραφεί (tamper) και υπογράφει νέα tokens με claims της επιλογής μας.

Πού ταιριάζει: στο τελευταίο βήμα. Έχουμε ήδη το signing secret από το sqlmap· το jwt_tool μας επιτρέπει (α) να το επιβεβαιώσουμε ανεξάρτητα σπάζοντάς το, (β) να δείξουμε ότι το API δέχεται alg:none, και (γ) να κατασκευάσουμε ένα token με role: admin που ο server θα δεχτεί.

Σημαντικές παράμετροι / flags

Βήμα 4α — Σπάσιμο του αδύναμου secret

Πήραμε πρώτα ένα κανονικό guest token κάνοντας login (guest:guest) και το δώσαμε στο jwt_tool σε crack mode:

jwt_tool <GUEST_JWT> -C -d wordlists/jwt-secrets.txt

Το jwt_tool επιβεβαίωσε μέσα σε χιλιοστά του δευτερολέπτου: helios123 is the CORRECT key!. Δύο ανεξάρτητες διαδρομές οδήγησαν στο ίδιο secret — το sqlmap το διάβασε από τη βάση, το jwt_tool το μάντεψε από ένα μικρό λεξικό. Αυτό είναι σημαντικό: ακόμα κι αν δεν υπήρχε η SQL injection, το secret ήταν εξ αρχής αδύναμο και θα έπεφτε σε ένα offline dictionary attack. Ο επιτιθέμενος δεν χρειάζεται καν πρόσβαση στον server για να το σπάσει — αρκεί ένα οποιοδήποτε valid token.

Βήμα 4β — Πλαστογράφηση admin token (HS256 + alg:none)

Με το secret στα χέρια μας, κατασκευάσαμε ένα token με role: admin, υπογεγραμμένο σωστά με HS256:

jwt_tool <GUEST_JWT> -I -pc role -pv admin -pc sub -pv attacker \
  -S hs256 -p helios123

Και, παράλληλα, δείξαμε τη «δωρεάν» παραλλαγή που δεν χρειάζεται καν secret — το alg:none exploit:

jwt_tool <GUEST_JWT> -X a -I -pc role -pv admin -pc sub -pv attacker

Το screenshot αποτυπώνει ολόκληρη την κατάληξη. Πρώτα, ως negative control, στείλαμε το αρχικό guest token στο /api/admin: ο server απάντησε σωστά {"error":"forbidden: admin role required"} — δηλαδή ο έλεγχος ρόλου υπάρχει και λειτουργεί. Έπειτα στείλαμε το forged HS256 admin token: ο server απάντησε {"message":"Welcome, Helios administrator.", "flag":"flag{audax_lab_api_jwt_alg_none_and_weak_secret}"}. Και το alg:none token έδωσε ακριβώς το ίδιο αποτέλεσμα — πρόσβαση admin χωρίς καμία υπογραφή.

Η αλυσίδα ολοκληρώθηκε: ffuf -> arjun -> sqlmap -> jwt_tool -> admin + flag.

Η αλυσίδα σε μια εικόνα και η αντιστοίχιση σε MITRE ATT&CK

Κάθε βήμα αυτής της αλυσίδας δεν είναι μια αφηρημένη «τεχνική hacking»· είναι μια συμπεριφορά που η κοινότητα άμυνας έχει καταγράψει, ονοματίσει και κωδικοποιήσει στο MITRE ATT&CK. Η αντιστοίχιση δεν είναι ακαδημαϊκή άσκηση: είναι ο τρόπος που μια Blue Team μετράει κάλυψη — δηλαδή, «για κάθε ένα από αυτά τα βήματα, έχω detection;».

Η κάλυψη εκτείνεται από το Reconnaissance (T1595.003) στο Initial Access (T1190), στο Credential Access (T1552.001) και τελικά στην κατάχρηση authentication material (T1550.001). Αν μια ομάδα άμυνας έχει detections σε έστω δύο από αυτά τα σημεία, η αλυσίδα σπάει — και ακριβώς αυτό είναι το ζητούμενο.

Επαλήθευση: γιατί ξέρουμε ότι δούλεψε πραγματικά

Στο πνεύμα των Audax Labs, δεν αρκεί το «έβγαλε flag». Επαληθεύσαμε κάθε κρίκο με ανεξάρτητο τρόπο:

• ffuf: τα status codes 401/405 δεν είναι «μαντεψιά» — αντικατοπτρίζουν πραγματικά τη λογική του API (authentication guard, method guard). Επιβεβαιώσαμε χειροκίνητα ότι το /api/admin χωρίς token επιστρέφει 401.
• arjun: το εύρημα category επαληθεύτηκε άμεσα — ?category=audio επιστρέφει διαφορετικό (μικρότερο) σύνολο προϊόντων από ό,τι χωρίς parameter. Η ανίχνευση «based on: body length» είναι αληθής και αναπαραγώγιμη.
• sqlmap: το dump των πινάκων συμφωνεί απόλυτα με το πραγματικό περιεχόμενο της βάσης (το επιβεβαιώσαμε με ανεξάρτητο UNION query μέσω curl). Δεν υπάρχει false positive.
• jwt_tool: το cracked secret (helios123) ταυτίζεται με το secret που διέρρευσε το sqlmap — δύο ανεξάρτητες πηγές, ίδιο αποτέλεσμα.
• flag: η πρόσβαση στο /api/admin αποτυγχάνει με το guest token (403) και πετυχαίνει και με τα δύο forged tokens. Αυτό το negative control αποκλείει το ενδεχόμενο να «δούλεψε» η επίθεση επειδή ο έλεγχος ρόλου απλώς δεν υπήρχε.

Το flag που ανακτήθηκε ήταν: flag{audax_lab_api_jwt_alg_none_and_weak_secret}.

Αντιμετώπιση προβλημάτων (troubleshooting) που συναντήσαμε

Καταγράφουμε τα πραγματικά εμπόδια, στο πνεύμα διαφάνειας:

• Docker daemon μη διαθέσιμος: όπως εξηγήσαμε, ο daemon ήταν ανενεργός και δεν είχαμε δικαίωμα εκκίνησης χωρίς sudo. Λύση: απομονωμένο loopback αντί για internal docker network. Ισοδύναμη απομόνωση, δηλωμένη ρητά.
• UNION SQLi μέσω curl χρειαζόταν URL-encoding: όταν δοκιμάσαμε χειροκίνητα το payload, τα κενά και το σχόλιο -- έσπαγαν το request. Λύση: curl -G --data-urlencode. Το sqlmap, φυσικά, χειρίζεται μόνο του το encoding.
• arjun & sqlmap δεν ήταν εγκατεστημένα στο σύστημα: τα εγκαταστήσαμε μέσα σε Python virtual environment (pip install arjun sqlmap), χωρίς global εγκατάσταση, χωρίς root. Το ffuf το τρέξαμε ως τοπικό, στατικό Go binary.
• jwt_tool πρώτη εκτέλεση: στο πρώτο τρέξιμο δημιούργησε το jwtconf.ini και τερμάτισε. Απλώς το ξανατρέξαμε — αναμενόμενη συμπεριφορά αρχικοποίησης.

Κανένα από αυτά δεν αλλοίωσε το αποτέλεσμα· περιγράφουν πραγματικές αποφάσεις μηχανικής σε ένα εργαστήριο.

Δυνατά σημεία της προσέγγισης

• Ρεαλισμός: η αλυσίδα αναπαράγει ένα απολύτως σύνηθες μοτίβο πραγματικών παραβιάσεων APIs — κρυφό parameter, injection, διαρροή secret, κατάχρηση token.
• Ανεξάρτητη επαλήθευση: κάθε εύρημα διασταυρώθηκε με δεύτερη μέθοδο, χωρίς να βασιστούμε τυφλά στο «πράσινο» ενός εργαλείου.
• Διαφάνεια: δηλώσαμε ρητά τι είναι πραγματικό (όλα τα outputs των εργαλείων) και τι είναι εργαστηριακή σύμβαση (η οπτική διεύθυνση 10.10.10.30 αντί για 127.0.0.1).
• Επαναληψιμότητα: όλα τρέχουν τοπικά, χωρίς εξωτερικές εξαρτήσεις, με καθορισμένες εκδόσεις εργαλείων.

Περιορισμοί και αδυναμίες

• Ελεγχόμενος στόχος: ο στόχος είναι σκόπιμα ευάλωτος. Στην πράξη, ένα σκληρυμένο API θα σταματούσε την αλυσίδα σε πολλαπλά σημεία (rate limiting στο ffuf/arjun, parameterised queries κατά του sqlmap, σωστή JWT verification κατά του jwt_tool).
• SQLite: επιλέξαμε SQLite για ελαφρότητα· ένα production DBMS (PostgreSQL, MySQL) έχει διαφορετική συμπεριφορά, αλλά η αρχή της injection είναι ίδια.
• Μοντελοποίηση δικτύου: η οπτική διεύθυνση στα screenshots είναι εργαστηριακή σύμβαση για ευανάγνωστη αφήγηση — ο πραγματικός server άκουγε σε loopback.

Θέματα ασφάλειας κατά τη χρήση αυτών των εργαλείων

Τα τέσσερα εργαλεία είναι dual-use: ίδια δύναμη στα χέρια ενός pentester και ενός επιτιθέμενου. Πριν τα χρησιμοποιήσετε, ένας επαγγελματίας οφείλει να ελέγξει:

• Scope και εξουσιοδότηση: το ffuf, το arjun και ιδίως το sqlmap παράγουν μεγάλο όγκο requests και τροποποιούν δεδομένα (το --dump/stacked queries μπορεί να γράψει). Χρησιμοποιήστε τα μόνο εντός ρητά εξουσιοδοτημένου scope.
• Επιθετικότητα του sqlmap: υψηλά --level/--risk και techniques όπως stacked queries μπορούν να είναι καταστροφικά σε production. Σε εργαστήριο δεν πειράζει· σε πραγματικό assessment, ελέγχετε προσεκτικά.
• Χειρισμός των secrets που ανακτώνται: cracked JWT secrets, credentials και dumps είναι ευαίσθητα ευρήματα. Αποθηκεύστε τα με ασφάλεια, αναφέρετέ τα υπεύθυνα, μην τα αφήνετε σε logs ή screenshots (γι’ αυτό εδώ όλα είναι εργαστηριακά).
• jwt_tool & out-of-band: ορισμένα modes του jwt_tool κάνουν εξωτερικά requests (π.χ. jku/OOB checks). Ελέγξτε το jwtconf.ini πριν το τρέξετε σε ευαίσθητο περιβάλλον.

Πού μπορεί να χρησιμοποιηθεί επαγγελματικά

• API penetration testing: αυτή ακριβώς η μεθοδολογία — endpoint discovery, parameter discovery, injection testing, JWT analysis — είναι ο πυρήνας ενός σοβαρού web/API pentest.
• Adversary validation & purple teaming: η αλυσίδα προσφέρεται για να ελεγχθεί αν οι υπάρχουσες άμυνες (WAF, rate limiting, logging) πραγματικά ανιχνεύουν τα βήματα — adversary validation.
• Εκπαίδευση & internal labs: ιδανικό σενάριο για να καταλάβει μια ομάδα ανάπτυξης γιατί «μια μικρή SQLi» και «ένα αδύναμο secret» μαζί σημαίνουν πλήρη παραβίαση.
• Detection engineering: κάθε βήμα δίνει σαφή IOCs για τη δημιουργία και δοκιμή detection rules.

Πότε δεν πρέπει να χρησιμοποιηθεί

• Ποτέ σε συστήματα εκτός ρητά εξουσιοδοτημένου scope — είναι παράνομο.
• Ποτέ με επιθετικές sqlmap ρυθμίσεις σε production χωρίς σαφή συνεννόηση και backups.
• Ποτέ ως «απόδειξη ασφάλειας»: το ότι ένα αυτόματο εργαλείο δεν βρήκε κάτι δεν σημαίνει ότι δεν υπάρχει. Τα εργαλεία βλέπουν μεμονωμένα ευρήματα· την αλυσίδα τη βλέπει ο άνθρωπος.

Άμυνα: πώς σταματάτε κάθε βήμα της αλυσίδας

Εδώ βρίσκεται η ουσία για κάθε οργανισμό. Η αλυσίδα έχει πέντε κρίκους — και αρκεί να σπάσετε έναν για να αποτραπεί η καταστροφική έκβαση. Στην πράξη, όμως, θέλετε να σπάσετε όσο περισσότερους μπορείτε (defense in depth).

1. Authentication σε ΚΑΘΕ endpoint — όχι μόνο στα «ευαίσθητα»

• Το ffuf βρήκε το /api/admin επειδή υπήρχε και απαντούσε. Η άμυνα δεν είναι να το «κρύψετε» — είναι να επιβάλλετε authentication και authorization σε κάθε route by default, με deny-by-default λογική.
• Broken function/object level authorization (BOLA/BFLA) είναι η Νο.1 αδυναμία APIs: ελέγξτε ότι ο έλεγχος ρόλου γίνεται server-side σε κάθε endpoint, όχι επιλεκτικά.
• Μην βασίζεστε στην «αφάνεια» ενός endpoint. Το enumeration είναι δευτερόλεπτα δουλειάς.

2. Παραμετροποιημένα queries — τέλος στο string concatenation

• Ο μοναδικός, οριστικός τρόπος να σταματήσετε το sqlmap είναι prepared statements / parameterised queries. Ποτέ μην χτίζετε SQL με συνένωση strings από user input.
• Χρησιμοποιήστε ORM ή query builders με σωστό escaping. Εφαρμόστε input validation (allowlist τιμών για ένα category, π.χ. ένα enum).
• Ελαχιστοποιήστε τα δικαιώματα του DB user της εφαρμογής (least privilege): read-only όπου αρκεί, χωρίς πρόσβαση σε πίνακες secrets.

3. Μην αποθηκεύετε secrets εκεί που φτάνει μια injection

• Το app_secrets δεν έπρεπε ποτέ να είναι στην ίδια βάση, προσβάσιμο από τον ίδιο DB user. Χρησιμοποιήστε secrets manager (Vault, AWS/GCP/Azure Secrets Manager) ή, τουλάχιστον, environment variables εκτός βάσης.
• Ένα διαρρεύσαν secret πρέπει να είναι αχρηστεύσιμο: rotation, short-lived keys, key IDs.

4. Ισχυρά, τυχαία JWT secrets — και rotation

• Το helios123 έπεσε σε ένα λεξικό 14 λέξεων. Χρησιμοποιήστε τυχαίο secret τουλάχιστον 256-bit (π.χ. 32+ bytes από CSPRNG) για HS256, ή καλύτερα ασύμμετρη υπογραφή (RS256/ES256) με ιδιωτικό κλειδί που δεν φεύγει ποτέ από τον server.
• Rotate τα κλειδιά τακτικά και άμεσα μετά από κάθε υποψία διαρροής. Υποστηρίξτε πολλαπλά valid keys μέσω kid για ομαλή περιστροφή.

5. Απαγορεύστε το alg:none — και επιβάλετε allowlist αλγορίθμων

• Ο πιο σοβαρός κρίκος: ποτέ μην εμπιστεύεστε το πεδίο alg του token. Ρητά allowlist τον αναμενόμενο αλγόριθμο (π.χ. μόνο RS256) στη ρύθμιση της βιβλιοθήκης verification.
• Απορρίψτε κατηγορηματικά το alg:none και τις παραλλαγές του (None, NONE). Αποτρέψτε το key confusion (RS256->HS256) δηλώνοντας ρητά τον αλγόριθμο κατά το verify.
• Χρησιμοποιήστε ώριμες, ενημερωμένες βιβλιοθήκες JWT και ποτέ custom verification code (όπως ο ευάλωτος verifier του lab μας).

6. Short expiry, rate limiting, WAF, logging & detection

• Short-lived tokens (μικρό exp) + refresh tokens: περιορίζουν το παράθυρο εκμετάλλευσης ενός κλεμμένου/forged token.
• Rate limiting μπροστά από όλα τα endpoints: τα μαζικά requests του ffuf και του arjun γίνονται ανιχνεύσιμα και μπλοκάρονται. WAF με signatures για SQLi/anomalies προσθέτει ένα επιπλέον επίπεδο.
• Logging & detection: καταγράψτε αποτυχημένα auth, ασυνήθιστα status-code patterns (πολλά 401/404 σε σειρά = enumeration), SQL errors, και αλλαγές ρόλου εντός token. Χαρτογραφήστε τα detections στα T1595.003, T1190, T1552.001, T1550.001 για μετρήσιμη κάλυψη.

Αν εφαρμόσετε έστω τα σημεία 2 και 5, η συγκεκριμένη αλυσίδα δεν ολοκληρώνεται: είτε το sqlmap δεν βρίσκει injection, είτε το forged token απορρίπτεται στο verification.

Σύνοψη

Αυτή η αλυσίδα αποτυπώνει με σκληρή σαφήνεια πώς ένα «στεγνό» JSON API — χωρίς frontend, χωρίς ορατή επιφάνεια — γίνεται πλήρης παραβίαση διαχειριστή. Ένα κρυφό parameter, μια SQL injection, ένα secret αποθηκευμένο στη βάση, και ένα JWT authentication που εμπιστεύεται τον επιτιθέμενο: τέσσερα ανεξάρτητα, «διαχειρίσιμα» λάθη που, ενωμένα, δίνουν τον απόλυτο έλεγχο.

Το μήνυμα για κάθε οργανισμό είναι διπλό. Πρώτον, τα αυτόματα εργαλεία δεν βλέπουν αλυσίδες — βλέπουν μεμονωμένα ευρήματα, και συχνά τα βαθμολογούν χαμηλά. Μια «medium» SQLi και ένα «low» αδύναμο secret, μαζί, είναι critical. Δεύτερον, η άμυνα δεν είναι ένα «μαγικό» control· είναι πολλαπλά, επικαλυπτόμενα επίπεδα (auth σε κάθε route, parameterised queries, secrets εκτός βάσης, ισχυρά τυχαία κλειδιά, απαγόρευση alg:none, rate limiting, logging) που το καθένα σπάει τουλάχιστον έναν κρίκο. Η συνεχής χαρτογράφηση της επιφάνειας επίθεσης και η επαλήθευση με πραγματικές τεχνικές επίθεσης είναι ο μόνος τρόπος να ξέρετε — και όχι απλώς να υποθέτετε — ότι αυτά τα επίπεδα δουλεύουν.

Από το εργαστήριο, στο δικό σας περιβάλλον

Στα Audax Labs στήνουμε ελεγχόμενα σενάρια για να δείξουμε πώς σκέφτεται και δρα ένας επιτιθέμενος — από την ανακάλυψη μέχρι το admin token. Το ζητούμενο δεν είναι το εργαλείο· είναι η αλυσίδα και η απόδειξη ανθεκτικότητας.

Η Audax Cybersecurity μεταφέρει αυτή τη λογική στο δικό σας περιβάλλον μέσα από δομημένο penetration testing, adversary validation και συνεχή Continuous Threat Exposure Management με το Erevos AI — με τεκμηριωμένα ευρήματα, προτεραιοποίηση και σαφή απόδειξη για τις απαιτήσεις NIS2 & DORA.

Human-led. Machine-scaled. Technically proven.

Επισκεφθείτε το https://www.audax.gr για να μάθετε πώς μετατρέπουμε σενάρια σαν αυτό σε μετρήσιμη βελτίωση της ασφάλειάς σας.