Burp Suite στο Kali Linux — Μέρος 3: Scope, Session Handling, Macros & Extensions στην πράξη

Στο τρίτο μέρος της σειράς κλείνουμε τον κύκλο του χειροκίνητου web application penetration testing με τα εργαλεία που ξεχωρίζουν τον απλό χρήστη από τον επαγγελματία tester. Ορίζουμε στοχευμένο engagement με Target scope και Site map, χειριζόμαστε την κίνηση με Match and Replace, και —το σημαντικότερο— λύνουμε τον «γρίφο» που άφησε ανοιχτό το Μέρος 2: πώς κάνεις brute force σε μια φόρμα που προστατεύεται με per-request CSRF token. Η απάντηση είναι ένα session handling rule με macro, και το δείξαμε ζωντανά, με πραγματικά screenshots από το γραφικό περιβάλλον και μια νόμιμη, end-to-end επίθεση που πέτυχε εκεί που ο «ωμός» Intruder αποτυγχάνει. Κλείνουμε με τα Extensions και το BApp Store, και μια ειλικρινή σύγκριση Community έναντι Professional.

Εισαγωγή: από τα εργαλεία, στη μεθοδολογία

Στο Μέρος 1 της σειράς στήσαμε το θεμέλιο: εγκαταστήσαμε το Burp Suite Community Edition, ρυθμίσαμε τον proxy listener, εισαγάγαμε το CA πιστοποιητικό και υποκλέψαμε νόμιμα την πρώτη μας κίνηση. Στο Μέρος 2 περάσαμε από την παρατήρηση στον έλεγχο: Repeater, Intruder, Decoder και Comparer, δεμένα σε μια πραγματική ροή brute force. Εκεί όμως αφήσαμε επίτηδες μια εκκρεμότητα — έναν «γρίφο» που ταλαιπωρεί κάθε αρχάριο tester και που, αν δεν τον λύσεις, νομίζεις ότι το εργαλείο «χάλασε».

Ο γρίφος ήταν αυτός: όταν προσπαθήσαμε να κάνουμε brute force σε μια φόρμα login που προστατεύεται με per-request anti-CSRF token (ένα κρυφό πεδίο user_token που αλλάζει σε κάθε φόρτωση σελίδας), ο Intruder απέτυχε παντού. Κάθε αίτημα απορριπτόταν, γιατί το token που έστελνε ήταν «μπαγιάτικο» — είχε ήδη καταναλωθεί ή δεν ταίριαζε πια με το session. Στο Μέρος 2 παρακάμψαμε το πρόβλημα δουλεύοντας σε ένα endpoint χωρίς token. Στο Μέρος 3 το αντιμετωπίζουμε κατά μέτωπο.

Αυτή η μετάβαση —από «ξέρω να χρησιμοποιώ ένα εργαλείο» σε «ξέρω να στήνω μια μεθοδολογία που δουλεύει ενάντια σε πραγματικές άμυνες»— είναι ακριβώς αυτό που κάνει τη διαφορά σε ένα σοβαρό web application penetration testing. Οι σύγχρονες εφαρμογές έχουν CSRF tokens, session validation, rate limiting και anti-automation μηχανισμούς. Ένας tester που δεν ξέρει να τους χειριστεί απλώς παράγει false negatives — αναφέρει ότι «η φόρμα δεν είναι ευπαθής σε brute force» ενώ στην πραγματικότητα απλώς δεν κατάφερε να τη δοκιμάσει σωστά.

Για οργανισμούς που υπάγονται σε NIS2 και DORA, αυτή η διάκριση δεν είναι ακαδημαϊκή. Η συμμόρφωση σε NIS2 και DORA απαιτεί *αποδεδειγμένη* ανθεκτικότητα, και μια απόδειξη που στηρίζεται σε λανθασμένη μεθοδολογία δεν αξίζει τίποτα. Γι' αυτό, σε αυτό το άρθρο, δεν διαβάζουμε την τεκμηρίωση — στήνουμε το εργαλείο, χειριζόμαστε πραγματικές άμυνες και δείχνουμε με μετρήσιμο τρόπο τι λειτουργεί.

Όπως και στο Μέρος 2, όλες οι εικόνες του γραφικού περιβάλλοντος είναι πραγματικά screenshots από ζωντανή εκτέλεση του Burp Suite 2026.4.3, μέσα σε απομονωμένο εικονικό framebuffer, πάνω στο δικό μας DVWA.

Προαπαιτούμενα

Πριν ξεκινήσετε το Μέρος 3, χρειάζεστε:

• Ολοκληρωμένα τα Μέρος 1 και Μέρος 2. Θεωρούμε δεδομένα: εγκατεστημένο Burp Suite Community Edition, ρυθμισμένο proxy listener στο 127.0.0.1:8080, εισαγμένο CA πιστοποιητικό, και εξοικείωση με τον Repeater και τον Intruder (positions, payload sets, attack types).
• Λειτουργικό: Kali Linux ή οποιαδήποτε σύγχρονη διανομή Debian/Ubuntu. (Η δοκιμή μας έγινε σε Ubuntu 24.04 με kernel 6.17· οι εντολές είναι πανομοιότυπες σε Kali.)
• Burp Suite Community Edition 2026.4.3 (build 47818), η ίδια έκδοση με τα προηγούμενα μέρη, με ενσωματωμένο OpenJDK 25.
• Έναν απομονωμένο, νόμιμο στόχο. Χρησιμοποιήσαμε ξανά το DVWA (Damn Vulnerable Web Application) σε Docker, δεμένο μόνο στο loopback — αυτή τη φορά όμως με security level: High, ώστε το module Brute Force να επιβάλλει το per-request user_token.
• Docker για τον στόχο.

Νομικό και ηθικό πλαίσιο — απαράβατο. Τα session handling rules, τα macros και ο Intruder είναι εργαλεία αυτοματοποιημένης επίθεσης. Επιτρέπονται μόνο σε συστήματα που σας ανήκουν ή για τα οποία έχετε ρητή, γραπτή εξουσιοδότηση. Σε όλο αυτό το άρθρο στοχεύουμε αποκλειστικά στο δικό μας DVWA, σε απομονωμένο τοπικό δίκτυο.

Το εργαστηριακό περιβάλλον δοκιμών

Το lab είναι το ίδιο απομονωμένο περιβάλλον της σειράς, με μία κρίσιμη διαφορά στη ρύθμιση του στόχου.

• Host: Ubuntu 24.04, Docker.
• Στόχος: DVWA v1.10 σε Docker, δεμένος μόνο στο loopback, στο 127.0.0.1:8085. Η βάση αρχικοποιήθηκε (/setup.php) και το επίπεδο ασφαλείας τέθηκε σε High (/security.php). Στο High, το module Brute Force παράγει σε κάθε φόρτωση ένα νέο κρυφό πεδίο <input type='hidden' name='user_token' value='...'> και το επικυρώνει server-side σε κάθε υποβολή. Αυτό είναι το ακριβές anti-CSRF μοτίβο που σπάει τον «ωμό» Intruder.
• Έγκυρα διαπιστευτήρια lab: admin / password.
• Burp proxy listener: 127.0.0.1:8080.

Πραγματικά screenshots με εικονικό framebuffer (Xvfb). Όπως και στο Μέρος 2, θέλαμε πραγματικά στιγμιότυπα του Burp χωρίς να «αγγίξουμε» τον ζωντανό desktop του μηχανήματος (display :0). Σηκώσαμε έναν απομονωμένο X server σε ξεχωριστό display μέσα σε container (Xvfb :99 -screen 0 1600x1000x24), τρέξαμε εκεί το Burp (DISPLAY=:99), οδηγήσαμε το γραφικό περιβάλλον με xdotool και τραβήξαμε τα στιγμιότυπα με το import του ImageMagick. Έτσι, και τα 20 screenshots αυτού του άρθρου είναι πραγματικά — από την πραγματική εκτέλεση του εργαλείου, όχι σχηματικές αναπαραστάσεις.

Target Scope και Site Map: ορίζοντας το πεδίο του engagement

Πριν επιτεθείς, πρέπει να ξέρεις πού επιτίθεσαι — και, εξίσου σημαντικό, πού δεν επιτρέπεται να επιτεθείς. Στο Burp, αυτό το ορίζει το Target scope. Είναι το πρώτο βήμα κάθε επαγγελματικού engagement και ένας από τους πιο υποτιμημένους μηχανισμούς ασφαλείας του εργαλείου.

Καθώς περιηγηθήκαμε στο DVWA με τον proxy ενεργό, το Burp έχτισε αυτόματα το Site map — έναν ιεραρχικό χάρτη κάθε host, path και endpoint που «είδε». Στο εργαστήριό μας ο χάρτης γέμισε γρήγορα με τις σελίδες του DVWA: /, /login.php, /security.php και το δέντρο των /vulnerabilities/ (brute, csrf, sqli, exec κ.λπ.), με request και response για κάθε καταχώριση.

Το Site map δεν είναι απλώς λίστα. Είναι η επιφάνεια επίθεσης της εφαρμογής όπως τη «βλέπει» ο tester: κάθε παράμετρος, κάθε cookie, κάθε endpoint που αξίζει έλεγχο. Σε ένα πραγματικό assessment, αυτός ο χάρτης είναι το σημείο εκκίνησης για να αποφασίσεις πού θα εστιάσεις — και εδώ μπαίνει το scope.

Ορίσαμε το DVWA ως scope: Target → Scope → Add, με prefix http://127.0.0.1:8085/. Μόλις προστεθεί ένα item στο scope, το Burp προσφέρει κάτι πολύ χρήσιμο: να σταματήσει να καταγράφει στο ιστορικό οτιδήποτε είναι εκτός scope.

Αυτή η ερώτηση —«θέλετε ο Proxy να σταματήσει να στέλνει out-of-scope items στο ιστορικό;»— είναι ένας πραγματικός μηχανισμός ασφαλείας. Σε ένα engagement όπου περιηγείσαι και σε τρίτα sites (π.χ. CDNs, analytics, τρίτες υπηρεσίες), το scope εγγυάται ότι δεν καταγράφεις ούτε στοχεύεις κατά λάθος συστήματα εκτός εντολής. Είναι η τεχνική έκφραση του «rules of engagement»: το Burp μπορεί να περιορίσει Proxy logging, Scanner, Intruder targets και spidering μόνο στα in-scope hosts. Για έναν επαγγελματία, το να ξεκινά κάθε engagement ρυθμίζοντας σωστά το scope δεν είναι λεπτομέρεια — είναι θέμα νομικής και επιχειρησιακής υγιεινής.

Match and Replace: αυτόματη τροποποίηση της κίνησης

Μια από τις πιο πρακτικές λειτουργίες του Proxy είναι οι κανόνες Match and Replace: αυτόματες αντικαταστάσεις σε αιτήματα και αποκρίσεις που περνούν μέσα από το Burp. Αντί να αλλάζεις χειροκίνητα κάθε αίτημα (όπως στον Repeater), ορίζεις έναν κανόνα και το Burp εφαρμόζει την αλλαγή σε κάθε διερχόμενη κίνηση.

Στο Burp 2026, οι κανόνες βρίσκονται στο Settings → Tools → Proxy → HTTP match and replace rules. Το εργαλείο έρχεται με έτοιμους (απενεργοποιημένους) κανόνες — π.χ. για να προσποιείται διαφορετικό User-Agent (iPhone, Android, Windows) ή να αφαιρεί caching headers.

Δημιουργήσαμε έναν δικό μας κανόνα για επίδειξη: αντικατάσταση του header User-Agent με μια custom τιμή. Το εντυπωσιακό είναι ο live preview: το Burp δείχνει δίπλα-δίπλα το «Original request» και το «Auto-modified request», ώστε να επιβεβαιώσεις τον κανόνα πριν τον ενεργοποιήσεις.

Πού χρησιμεύει στην πράξη; Σε πολλά καθημερινά σενάρια offensive testing:

• Bypass client-side ελέγχων: αν μια εφαρμογή στέλνει X-Frame-Options ή κάνει redirect με βάση headers, ένας κανόνας match & replace μπορεί να τα «πειράξει» για να αναλύσεις τη συμπεριφορά.
• Session/token manipulation: αντικατάσταση ενός Authorization header ή cookie σε όλα τα αιτήματα, ώστε να δοκιμάσεις μαζικά μια συνεδρία.
• Feature flags & UI unlocking: αλλαγή μιας response τιμής (π.χ. "isAdmin":false → "isAdmin":true) για να δεις αν η εφαρμογή εμπιστεύεται client-side δεδομένα — κλασικό business-logic finding.
• User-Agent / device spoofing: για να δοκιμάσεις πώς συμπεριφέρεται η εφαρμογή σε διαφορετικές συσκευές.

Ο κανόνας match & replace είναι, ουσιαστικά, αυτοματοποιημένη «χειραγώγηση της κίνησης σε κλίμακα» — ό,τι κάνεις χειροκίνητα στον Repeater, αλλά σε κάθε αίτημα, αυτόματα.

Session Handling & Macros: λύνοντας τον γρίφο του CSRF token

Φτάνουμε στην καρδιά του Μέρους 3 — και στη λύση της εκκρεμότητας του Μέρους 2.

Το πρόβλημα, ξανά. Η φόρμα Brute Force του DVWA σε security High περιλαμβάνει ένα κρυφό πεδίο user_token. Σε κάθε φόρτωση σελίδας, ο server παράγει ένα νέο τυχαίο token και το αποθηκεύει στο session. Σε κάθε υποβολή, ελέγχει ότι το user_token που στέλνεις ταιριάζει με αυτό που έχει στο session. Αν όχι — απόρριψη.

Ο «ωμός» Intruder στέλνει το ίδιο, στατικό token σε κάθε αίτημα. Το πρώτο ίσως περάσει· όλα τα υπόλοιπα απορρίπτονται, γιατί το token έχει «καεί». Το επιβεβαιώσαμε και εκτός Burp: όταν ξαναχρησιμοποιήσαμε ένα μπαγιάτικο token, ο DVWA απάντησε με HTTP 302 redirect προς index.php — δηλαδή απόρριψη, όχι επεξεργασία της υποβολής.

Η λύση: session handling rule + macro. Το Burp λύνει ακριβώς αυτό το πρόβλημα με έναν κομψό μηχανισμό. Ένα session handling rule είναι μια σειρά ενεργειών που το Burp εκτελεί πριν από κάθε αίτημα που στέλνει ένα εργαλείο (π.χ. ο Intruder). Μία από αυτές τις ενέργειες μπορεί να είναι «τρέξε ένα macro» — μια προκαθορισμένη ακολουθία αιτημάτων. Ο συνδυασμός είναι απλός στη σύλληψη και ισχυρός στην πράξη:

Πριν από κάθε προσπάθεια brute force, το macro φορτώνει ξανά τη σελίδα, «διαβάζει» το νέο user_token από την απόκριση, και το εμφυτεύει στο επόμενο αίτημα του Intruder. Έτσι κάθε αίτημα φέρει ένα φρέσκο, έγκυρο token.

Ας το στήσουμε βήμα-βήμα, όπως το κάναμε στο εργαστήριο.

Βήμα 1 — Το session handling rule

Στο Settings → Sessions βρίσκουμε τα Session handling rules. Υπάρχει ήδη ένας προεπιλεγμένος κανόνας («Use cookies from Burp's cookie jar»). Προσθέτουμε δικό μας.

Στον editor του κανόνα, δίνουμε περιγραφή («DVWA Brute Force – fetch fresh CSRF user_token») και προσθέτουμε μια rule action. Το Burp προσφέρει πολλούς τύπους ενεργειών· εμάς μας ενδιαφέρει το «Run a macro».

Βήμα 2 — Καταγραφή του macro

Επιλέγοντας «Run a macro» και μετά «Add», ανοίγει ο Macro Recorder. Αυτός δείχνει το Proxy history και μας αφήνει να επιλέξουμε ποια αιτήματα θα αποτελέσουν το macro. Επιλέξαμε το GET /vulnerabilities/brute/ — το αίτημα που, στην απόκρισή του, περιέχει το φρέσκο user_token.

Στον Macro Editor βλέπουμε το macro item και, κρίσιμα, μια στήλη «Derived parameters» — εδώ ορίζουμε ποια τιμή θα «εξάγει» το Burp από την απόκριση.

Βήμα 3 — Εξαγωγή του token (το κρίσιμο σημείο)

Πατάμε Configure item και, στην ενότητα «Custom parameter locations in response», Add. Εδώ λέμε στο Burp *πού ακριβώς* βρίσκεται το token μέσα στην απόκριση.

Στον διάλογο «Define custom parameter» ορίσαμε:

• Parameter name: user_token
• Start after expression: name='user_token' value='
• End at delimiter: '

Το Burp εντόπισε αυτόματα το token μέσα στην πραγματική απόκριση — το κρυφό πεδίο <input type='hidden' name='user_token' value='944dc186d1db81b3e14feada2e17eb99' /> — και επιβεβαίωσε τη σύλληψη με «1 highlight».

Βήμα 4 — Δοκιμή του macro

Πριν το χρησιμοποιήσουμε, το δοκιμάσαμε με Test macro. Το Burp έτρεξε το macro live και στην απόκριση φάνηκε ένα νέο token, 33c73cc9e7e9da323b6258511c4da2d0 — διαφορετικό από το προηγούμενο. Αυτό αποδεικνύει το ζητούμενο: το macro φέρνει φρέσκο token σε κάθε εκτέλεση.

Βήμα 5 — Σύνδεση του macro με τον κανόνα και το scope

Επιστρέφοντας στον κανόνα, η ενέργεια εμφανίζεται πλέον ως «run macro: Macro 1».

Στην καρτέλα Scope του κανόνα ορίζουμε σε ποια εργαλεία και σε ποιες διευθύνσεις εφαρμόζεται. Κρίσιμα, το Intruder πρέπει να είναι επιλεγμένο στα Tools scope, και θέσαμε το URL scope να ακολουθεί το suite scope (το DVWA που ορίσαμε νωρίτερα).

Πλέον υπάρχουν δύο ενεργοί κανόνες, και ο δικός μας εφαρμόζεται στο Intruder.

Βήμα 6 — Ο Intruder ενάντια στη φόρμα με token

Τώρα στήσαμε τον Intruder όπως στο Μέρος 2 — αλλά αυτή τη φορά ενάντια στη φόρμα με token. Στείλαμε το αίτημα GET /vulnerabilities/brute/?username=admin&password=test123&Login=Login&user_token=... στον Intruder, καθαρίσαμε τις αυτόματες θέσεις, και ορίσαμε μία θέση payload: μόνο στην τιμή του password. Το user_token το αφήσαμε ως έχει στο αίτημα — το macro θα το αντικαθιστά αυτόματα με φρέσκια τιμή.

Φορτώσαμε το ίδιο μικρό wordlist με το Μέρος 2: admin, letmein, 123456, password, dvwa, root.

Το πρώτο τρέξιμο — και ένα πραγματικό «παγίδα» που αξίζει να ξέρετε

Εδώ συνέβη κάτι διδακτικό, που το κρατάμε στο άρθρο επειδή είναι *πραγματικό* και συμβαίνει σε κάθε αρχάριο.

Στο πρώτο τρέξιμο, όλα τα αιτήματα επέστρεψαν HTTP 200 (όχι 302!) — άρα το token handling δούλεψε: κάθε αίτημα έγινε αποδεκτό και επεξεργάστηκε, αντί να απορριφθεί με redirect. Όμως κανένας κωδικός δεν ξεχώρισε: όλα τα μήκη ήταν ίδια (4790), ακόμη και ο σωστός (password).

Ανοίγοντας το αίτημα #4 (password) είδαμε την αιτία:

GET /vulnerabilities/brute/?username=&password=password&Login=Login&user_token=79bab1c8d688612576897037ff2f3c33 HTTP/1.1

Το user_token ήταν φρέσκο (79bab1c8..., διαφορετικό από το αρχικό 2c0885f8...) — άρα το macro δούλευε τέλεια. Αλλά το username= είχε αδειάσει! Η ρύθμιση του macro action «Update all parameters and headers» έκανε το Burp να αντικαταστήσει *όλες* τις παραμέτρους που ταίριαζαν με πεδία της φόρμας — και επειδή στη φόρμα το πεδίο username είναι κενό, το Burp το «άδειασε» και στο αίτημα. Χωρίς username, το login αποτυγχάνει ακόμη κι αν ο κωδικός είναι σωστός.

Η διόρθωση ήταν ακριβής: στο macro action αλλάξαμε από «Update all parameters» σε «Update only the following parameters and headers» και δηλώσαμε μόνο user_token. Έτσι το Burp αντικαθιστά αποκλειστικά το token και αφήνει ανέγγιχτα το username=admin και το payload του password.

Αυτή η λεπτομέρεια είναι η ουσία του επαγγελματικού testing: το εργαλείο έκανε *ακριβώς* ό,τι του ζητήσαμε — απλώς του ζητήσαμε λάθος πράγμα. Η διάγνωση απαιτούσε να διαβάσουμε το πραγματικό αίτημα, όχι να υποθέσουμε.

Το αποτέλεσμα: brute force σε token-protected φόρμα, με απόδειξη

Με τη διόρθωση, ξανατρέξαμε την επίθεση. Το αποτέλεσμα ήταν καθαρό:

Δύο ανεξάρτητα «μαντεία» προδίδουν την επιτυχία:

1. Length: το αίτημα #4 (password) έχει μήκος 4828 — ξεκάθαρα διαφορετικό από τα 4790 όλων των αποτυχιών. Η διαφορά αντιστοιχεί στο μήνυμα «Welcome to the password protected area admin».
2. Χρόνος απόκρισης: όλες οι αποτυχίες έχουν καθυστέρηση 1001–3001 ms (ο anti-brute-force sleep του DVWA High). Η επιτυχία απαντά σε 1 ms — γιατί στην επιτυχία δεν υπάρχει καθυστέρηση. Αυτό είναι ένα κλασικό timing oracle.

Ανοίγοντας το αίτημα #4, η απόδειξη ήταν πλήρης:

GET /vulnerabilities/brute/?username=admin&password=password&Login=Login&user_token=688b2267504f99ae8192fd276d7d1b72 HTTP/1.1

Το username=admin διατηρήθηκε, το password=password (το payload) πέρασε, και το user_token=688b2267... ήταν φρέσκο — εμφυτευμένο από το macro. Στην απόκριση: «Welcome to the password protected area admin».

Με άλλα λόγια: λύσαμε τον γρίφο του Μέρους 2. Ο Intruder, που «ωμά» αποτυγχάνει σε κάθε token-protected φόρμα, δουλεύει τέλεια όταν τον συνδυάσεις με ένα session handling rule και ένα macro. Και το αποδείξαμε end-to-end, με πραγματική έξοδο, ενάντια σε ενεργή CSRF άμυνα.

Extensions & BApp Store: επεκτείνοντας το Burp

Ένα από τα μεγαλύτερα πλεονεκτήματα του Burp είναι το οικοσύστημα extensions. Στην καρτέλα Extensions διαχειρίζεστε πρόσθετα γραμμένα σε Java, Python (μέσω Jython) ή Kotlin, που προσθέτουν νέες λειτουργίες — από παθητικούς ελέγχους μέχρι ολόκληρα νέα εργαλεία μέσα στο UI.

Το BApp Store είναι το επίσημο «κατάστημα» extensions της PortSwigger. Περιλαμβάνει δεκάδες εργαλεία, πολλά από τα οποία είναι de facto standard στο web-app testing.

Ανάμεσα στα πιο χρήσιμα:

• JWT Editor (που φαίνεται στο screenshot): ανάλυση και επίθεση σε JSON Web Tokens — αλλαγή claims, none algorithm attack, HMAC key confusion, embedded JWK. Απαραίτητο για σύγχρονο API testing.
• Turbo Intruder: μηχανή Python για επιθέσεις υπερ-υψηλής ταχύτητας — παρακάμπτει το throttling παρέχοντας δικό της request engine (χρήσιμο ακόμη και σε Community).
• Param Miner: ανακάλυψη κρυφών παραμέτρων και headers (cache poisoning, hidden inputs).
• Autorize: αυτόματος έλεγχος authorization — δοκιμάζει κάθε αίτημα με διαπιστευτήρια χαμηλότερου προνομίου για να βρει IDOR/broken access control.
• Logger++: προηγμένο, με φίλτρα, logging όλης της κίνησης από όλα τα εργαλεία.

Προσοχή στη συμβατότητα. Στο BApp Store, ορισμένα extensions φέρουν την ένδειξη ότι απαιτούν Burp Suite Professional (τυπικά όσα ενσωματώνονται με τον ενεργό Scanner). Στην Community εγκαθίστανται και λειτουργούν πολλά —όπως το JWT Editor, το Turbo Intruder ή το Autorize— αλλά όχι όλα. Πάντα ελέγξτε την ένδειξη «Pro» πριν βασιστείτε σε ένα extension.

Η εγκατάσταση ενός extension από το BApp Store είναι υπόθεση ενός κλικ («Install»). Για custom extensions, το subtab Installed → Add σας επιτρέπει να φορτώσετε ένα δικό σας .jar ή Python script — έτσι ομάδες γράφουν εσωτερικά εργαλεία προσαρμοσμένα στις δικές τους ανάγκες testing.

Community έναντι Professional: η ειλικρινής εικόνα

Αφού καλύψαμε τα βασικά εργαλεία σε τρία μέρη, αξίζει μια ξεκάθαρη σύγκριση — γιατί κυκλοφορεί πολλή σύγχυση.

Τι σας δίνει πλήρως η Community (δωρεάν):

• Proxy, Repeater, Decoder, Comparer, Sequencer, Logger — χωρίς περιορισμό.
• Target scope & Site map, Match and Replace, Session handling rules & Macros (όλα όσα κάναμε σήμερα).
• Intruder — αλλά με χρονικό throttling (σκόπιμα αργός σε μεγάλες επιθέσεις) και κλειδωμένα κάποια έτοιμα wordlists.
• Extensions & BApp Store (τα Community-compatible).

Τι κλειδώνει η Professional:

• Ενεργός Scanner (DAST): ο αυτόματος σαρωτής ευπαθειών του Burp. Είναι Professional-only — δεν υπάρχει καθόλου στην Community. Ελέγχει ενεργά για SQLi, XSS, SSRF, injection κ.λπ. και παράγει δομημένα ευρήματα.
• Intruder χωρίς throttling και με πλήρη σύνολα payload.
• Αποθήκευση project (η Community κρατά μόνο προσωρινά projects στη μνήμη).
• Επιπλέον εργαλεία (Collaborator client πλήρες, project-wide search κ.ά.).

Τι σημαίνει «passive» στην Community. Παρότι ο ενεργός Scanner λείπει, η Community εξακολουθεί να προσφέρει αξία στην ανάλυση: μπορείτε να επιθεωρήσετε χειροκίνητα κάθε request/response, να χρησιμοποιήσετε τον Comparer για blind ευπάθειες, τον Sequencer για entropy analysis, και extensions όπως το Retire.js ή το Active Scan++ (όπου συμβατά) για επιπλέον παθητικές ενδείξεις. Δεν παίρνετε αυτόματο «κουμπί σάρωσης» — αλλά παίρνετε όλα τα εργαλεία για χειροκίνητο έλεγχο, που είναι και ο σωστός τρόπος να μάθει κανείς.

Το συμπέρασμα για επαγγελματίες: η Community είναι εξαιρετική για εκμάθηση, για στοχευμένο χειροκίνητο testing και για μικρές δοκιμές. Για assessment σε κλίμακα, με αυτόματο DAST, αποθήκευση ευρημάτων και ταχύτητα, η Professional (ή, ακόμη καλύτερα, μια ολοκληρωμένη μεθοδολογία) γίνεται αναγκαία.

Δυνατά σημεία

• Session handling & macros: ο μηχανισμός που ξεχωρίζει το Burp από απλούς HTTP proxies. Λύνει καθαρά το πρόβλημα CSRF tokens, authenticated flows και re-login — και είναι διαθέσιμος δωρεάν στην Community.
• Ενοποιημένο scope: ένας μηχανισμός που ταυτόχρονα εστιάζει την εργασία και προστατεύει από out-of-scope σφάλματα.
• Match and Replace με live preview: αυτοματοποίηση χειραγώγησης κίνησης, με άμεση επιβεβαίωση πριν την ενεργοποίηση.
• Οικοσύστημα extensions: το BApp Store μετατρέπει το Burp σε πλατφόρμα — από JWT attacks μέχρι authorization testing, υπάρχει extension για σχεδόν κάθε ανάγκη.
• Διαφάνεια Community/Pro: το εργαλείο δηλώνει ρητά τι είναι κλειδωμένο, χωρίς «κρυφά» εμπόδια.

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

• Καμπύλη μάθησης των macros: το session handling είναι ισχυρό αλλά όχι προφανές. Η παγίδα «Update all parameters» που συναντήσαμε είναι κλασική· χωρίς προσεκτική ανάγνωση του πραγματικού αιτήματος, μπερδεύεσαι εύκολα.
• Χωρίς ενεργό Scanner στην Community: ο αυτόματος DAST είναι Professional-only. Για ομάδες που περιμένουν «κουμπί σάρωσης», αυτό είναι σημαντικός περιορισμός.
• Intruder throttling: παραμένει, όπως και στο Μέρος 2. Για επιθέσεις με token σε κλίμακα, ο συνδυασμός macro + throttling κάνει την Community αργή (αν και το Turbo Intruder extension βοηθά).
• Χωρίς αποθήκευση project: τα temporary projects χάνονται στο κλείσιμο· τα session handling rules και macros πρέπει να ξαναστηθούν ή να εξαχθούν μέσω configuration.
• Debugging: όταν ένα session handling rule δεν δουλεύει, ο «Sessions tracer» βοηθά, αλλά η διάγνωση απαιτεί εμπειρία.

Θέματα ασφάλειας κατά τη χρήση

• Στοχεύετε μόνο σε ό,τι σας ανήκει ή έχετε ρητή εξουσιοδότηση. Macros και Intruder είναι εργαλεία αυτοματοποιημένης επίθεσης — η μη εξουσιοδοτημένη χρήση είναι παράνομη.
• Το scope είναι μηχανισμός ασφαλείας, όχι μόνο ευκολία. Ρυθμίστε το σωστά στην αρχή κάθε engagement για να μην καταγράψετε ή στοχεύσετε κατά λάθος out-of-scope συστήματα.
• Προσοχή στα macros που κάνουν login: αν ένα macro περιλαμβάνει διαπιστευτήρια, αυτά αποθηκεύονται στη ρύθμιση — μην μοιράζεστε configuration files με πραγματικά credentials.
• Rate & lockouts: ακόμη και σε νόμιμο στόχο, το session handling προσθέτει επιπλέον αιτήματα (το macro τρέχει *πριν* από κάθε αίτημα), διπλασιάζοντας τον όγκο κίνησης. Προσοχή σε lockouts και DoS.
• Extensions = τρίτος κώδικας: ένα BApp εκτελείται μέσα στο Burp με τα δικαιώματά του. Εγκαθιστάτε extensions από το επίσημο BApp Store και ελέγχετε το «System impact».

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

• Web/API penetration testing: το session handling είναι απαραίτητο για authenticated testing σε σχεδόν κάθε σύγχρονη εφαρμογή — CSRF tokens, JWT refresh, OAuth flows.
• Red Team & adversary emulation: αυτοματοποιημένες επιθέσεις σε token-protected endpoints, στο πλαίσιο επικύρωσης αντιπάλου (adversary validation).
• DevSecOps: έλεγχος authenticated API flows κατά την ανάπτυξη, με macros που διαχειρίζονται tokens και sessions.
• Detection engineering (Blue Team): κατανοώντας πώς μοιάζει η κίνηση μιας επίθεσης που «σέβεται» τα CSRF tokens, γράφετε καλύτερους κανόνες ανίχνευσης — που δεν βασίζονται μόνο σε «στατικό token σε πολλά αιτήματα».
• Εκπαίδευση & labs: το κατεξοχήν σενάριο για να μάθει μια ομάδα πώς λειτουργούν πραγματικά οι anti-CSRF άμυνες — και γιατί δεν αρκούν από μόνες τους.

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

• Ενάντια σε οποιοδήποτε σύστημα χωρίς ρητή εξουσιοδότηση.
• Ως υποκατάστατο σωστής μεθοδολογίας: το να «περνά» ο Intruder ένα token δεν σημαίνει ότι βρήκατε ευπάθεια — απλώς ότι δοκιμάσατε σωστά. Η ερμηνεία απαιτεί ανθρώπινη κρίση.
• Σε παραγωγικά συστήματα χωρίς έλεγχο ρυθμού — το session handling διπλασιάζει τα αιτήματα.
• Ως αυτόματος σαρωτής: για DAST χρειάζεται ο Scanner της Professional· η Community είναι εργαλείο χειροκίνητου ελέγχου.

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

• «Το session handling rule δεν φαίνεται να εφαρμόζεται». Ελέγξτε την καρτέλα Scope του κανόνα: το σωστό εργαλείο (π.χ. Intruder) πρέπει να είναι επιλεγμένο, και το URL scope να καλύπτει τον στόχο. Χρησιμοποιήστε το Open sessions tracer για να δείτε βήμα-βήμα τι κάνει το Burp πριν από κάθε αίτημα.
• «Ο Intruder επιστρέφει 302 παντού». Το macro δεν αντικαθιστά σωστά το token. Επιβεβαιώστε το custom parameter (user_token, σωστά delimiters) με Test macro — πρέπει να βλέπετε φρέσκο token σε κάθε δοκιμή.
• «Ακόμη και ο σωστός κωδικός αποτυγχάνει». Η παγίδα που περιγράψαμε: το «Update all parameters» αδειάζει άλλες παραμέτρους (π.χ. username). Αλλάξτε σε «Update only the following parameters» και δηλώστε μόνο user_token. Διαβάστε το πραγματικό αίτημα (αίτημα #N → Request) για επιβεβαίωση.
• «Το token είναι URL-agnostic / αλλάζει path». Στο action editor, ενεργοποιήστε το «Tolerate URL mismatch when matching parameters (use for URL-agnostic CSRF tokens)».
• «Ένα extension δεν φορτώνει». Ελέγξτε το subtab Errors στο Extensions· τα Jython/Python extensions χρειάζονται ρυθμισμένο Jython standalone jar στα Extensions settings.
• Για πραγματικά screenshots χωρίς desktop: σηκώστε Xvfb :99 -screen 0 1600x1000x24, τρέξτε το Burp με DISPLAY=:99, οδηγήστε το UI με xdotool και τραβήξτε με import -window root out.png.

Τι κλείσαμε — και τι ακολουθεί

Με το Μέρος 3 κλείνει ο βασικός κύκλος της σειράς. Σε τρία μέρη περάσαμε:

• Μέρος 1: εγκατάσταση, proxy, CA, πρώτη υποκλοπή — η ορατότητα.
• Μέρος 2: Repeater, Intruder, Decoder, Comparer — ο έλεγχος της κίνησης.
• Μέρος 3: scope, match & replace, session handling & macros, extensions — η μεθοδολογία που δουλεύει ενάντια σε πραγματικές άμυνες.

Ένας tester που κατέχει αυτά τα τρία επίπεδα έχει το θεμέλιο για σοβαρό web application penetration testing. Από εδώ και πέρα, το ταξίδι συνεχίζεται σε βάθος: authenticated API testing με OAuth/JWT, εξειδικευμένα extensions, ο ενεργός Scanner της Professional σε βάθος, και προηγμένες τεχνικές (HTTP request smuggling, cache poisoning, race conditions). Αν υπάρξει ενδιαφέρον, θα καλύψουμε αυτά τα θέματα σε επόμενα, εξειδικευμένα εργαστήρια.

Τελική αξιολόγηση

Για το αντικείμενο του Μέρους 3 — τη μεθοδολογία που κάνει το Burp εργαλείο επαγγελματικού επιπέδου — η εικόνα είναι ξεκάθαρη. Το session handling με macros είναι από τα πιο ισχυρά και υποτιμημένα χαρακτηριστικά κάθε web-app εργαλείου, και το γεγονός ότι είναι πλήρως διαθέσιμο στη δωρεάν Community το κάνει ασύγκριτης αξίας. Το scope, το match & replace και το BApp Store συμπληρώνουν ένα ώριμο, ολοκληρωμένο περιβάλλον. Στο εργαστήριό μας, λύσαμε ένα πραγματικό πρόβλημα —brute force σε token-protected φόρμα— από άκρη σε άκρη, με μετρήσιμη απόδειξη επιτυχίας, και τεκμηριώσαμε ειλικρινά ακόμη και την «παγίδα» που συναντήσαμε στην πορεία. Για κάθε επαγγελματία και εκπαιδευόμενο στον έλεγχο ασφάλειας web εφαρμογών, η γνώση αυτών των μηχανισμών είναι θεμελιώδης — και η δωρεάν έκδοση αρκεί για να την αποκτήσετε σωστά.

Συμπέρασμα

Το Burp Suite δεν είναι ένα εργαλείο· είναι μια μεθοδολογία. Στο Μέρος 1 μάθαμε να *βλέπουμε* την κίνηση, στο Μέρος 2 να τη *χειριζόμαστε*, και στο Μέρος 3 να *χτίζουμε ροές* που αντέχουν απέναντι σε πραγματικές άμυνες. Η διαφορά ανάμεσα σε έναν χρήστη εργαλείου και έναν επαγγελματία tester δεν είναι το εργαλείο — είναι η ικανότητα να διαγνώσεις γιατί κάτι «δεν δουλεύει», να στήσεις τη σωστή ροή, και να μετατρέψεις μια λεπτή διαφορά (38 bytes, 1 millisecond) σε αποδεδειγμένο εύρημα. Αυτή η ικανότητα δεν έρχεται από την τεκμηρίωση· έρχεται από την πράξη — από το να στήσεις, να αποτύχεις, να διορθώσεις και να αποδείξεις. Ακριβώς όπως κάναμε εδώ.

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

Δεν διαβάζουμε απλώς για εργαλεία — τα στήνουμε, τα δοκιμάζουμε και επαληθεύουμε τι πραγματικά κάνουν, όπως ακριβώς κάναμε εδώ λύνοντας μια πραγματική επίθεση brute force ενάντια σε ενεργή CSRF άμυνα, σε στόχο που ελέγχουμε πλήρως. Την ίδια αυστηρότητα την εφαρμόζουμε συνεχώς στο δικό σας περιβάλλον μέσα από το Erevos AI, την ετήσια υπηρεσία Continuous Threat Exposure Management (CTEM) της Audax Cybersecurity: ένα managed πρόγραμμα τεχνικής επαλήθευσης κυβερνοανθεκτικότητας που ενοποιεί χαρτογράφηση έκθεσης, penetration testing, adversary emulation, detection validation και τεκμηριωμένη αποκατάσταση σε έναν συνεχή κύκλο ελέγχου, απόδειξης και προτεραιοποίησης κινδύνου — με άμεση αξία για τη συμμόρφωσή σας σε NIS2 και DORA και για τη συνεχή διαχείριση της επιφάνειας επίθεσης.

Human-led. Machine-scaled. Technically proven.

→ Δείτε το Erevos AI: https://www.audax.gr/erevos-ai/ → Χρειάζεστε στοχευμένο έλεγχο τώρα; Penetration testing & adversary validation από την ομάδα της Audax. Για συνεχή ορατότητα, δείτε το Continuous Exposure Management.