Cookies, Sessions & Authentication: Τα Βασικά

Πώς «θυμάται» ο server ότι έχεις κάνει login, ενώ το HTTP δεν κρατά μνήμη; Η απάντηση βρίσκεται στα cookies και στα sessions. Σε αυτό το εργαστηριακό άρθρο για αρχάριους βλέπουμε βήμα-βήμα πώς λειτουργεί ο μηχανισμός ταυτοποίησης (authentication) μέσω cookies — Set-Cookie headers, session id, καθώς και οι σημαίες ασφαλείας HttpOnly/Secure/SameSite — όλα μέσα σε ένα απομονωμένο (isolated) lab, με έμφαση στην κατανόηση και την άμυνα.

1. Γιατί έχει σημασία να καταλάβεις cookies & sessions

Το HTTP είναι stateless (χωρίς μνήμη κατάστασης): κάθε αίτημα (request) είναι ανεξάρτητο και ο server δεν «θυμάται» από μόνος του ποιος στέλνει το επόμενο. Κι όμως, όταν κάνεις login σε έναν ιστότοπο, παραμένεις συνδεδεμένος καθώς μετακινείσαι από σελίδα σε σελίδα. Πώς γίνεται αυτό; Με τα cookies και τα sessions — τον μηχανισμό που «κολλάει» μια ταυτότητα πάνω σε ένα κατά τα άλλα άμνημον πρωτόκολλο.

Για όποιον ξεκινά στην κυβερνοασφάλεια ή στο authorized penetration testing, αυτό δεν είναι λεπτομέρεια. Το session cookie είναι, στην ουσία, το «κλειδί» της συνεδρίας σου: όποιος το αποκτήσει μπορεί να παριστάνει εσένα χωρίς να ξέρει καν τον κωδικό σου. Επιθέσεις όπως το session hijacking και το cookie theft στοχεύουν ακριβώς αυτό. Ένας αμυντικός μηχανικός (defender) που καταλαβαίνει πώς ταξιδεύει ένα cookie μέσα στα headers μπορεί να ρυθμίσει σωστά τις σημαίες προστασίας και να εντοπίσει ανωμαλίες στα logs.

Γι’ αυτό ξεκινάμε από τα θεμέλια: τι είναι ένα cookie, πώς γεννιέται ένα session, και ποιες ρυθμίσεις κάνουν τη διαφορά ανάμεσα σε μια ασφαλή και μια ευάλωτη εφαρμογή.

2. Βασικές έννοιες

2.1 Τι είναι ένα cookie

Ένα cookie είναι ένα μικρό κομμάτι δεδομένων (ζεύγος όνομα=τιμή) που ο server ζητά από τον browser να αποθηκεύσει και να το ξαναστέλνει σε κάθε επόμενο request προς τον ίδιο ιστότοπο. Ο server το «δίνει» μέσω του header Set-Cookie στην απόκριση (response)· ο client το επιστρέφει μέσω του header Cookie στο επόμενο αίτημα. Έτσι ο server αναγνωρίζει ότι δύο ξεχωριστά requests προέρχονται από τον ίδιο χρήστη.

2.2 Τι είναι ένα session

Ένα session (συνεδρία) είναι η «κατάσταση» που κρατά ο server για έναν συνδεδεμένο χρήστη — π.χ. ποιος είναι, τι δικαιώματα έχει, τι έχει βάλει στο καλάθι. Ο server δεν στέλνει όλα αυτά τα δεδομένα στον browser. Αντ’ αυτού, δημιουργεί ένα μοναδικό, τυχαίο αναγνωριστικό, το session id (π.χ. session=8f3a…snip…), και το στέλνει ως cookie. Τα πραγματικά δεδομένα μένουν στον server· το cookie μεταφέρει μόνο το «εισιτήριο» που τα ξεκλειδώνει.

Γι’ αυτό ένα session id πρέπει να είναι μακρύ και απρόβλεπτο (τυχαία δημιουργημένο, high entropy). Αν μπορεί κανείς να το μαντέψει ή να το κλέψει, αποκτά την ίδια πρόσβαση με τον νόμιμο χρήστη.

2.3 Το authentication vs το session

Δύο έννοιες που συχνά μπερδεύονται:

• Authentication (ταυτοποίηση): η μία στιγμή που αποδεικνύεις ποιος είσαι — συνήθως με username + password στο /login.
• Session: το «θυμάμαι ότι μόλις ταυτοποιήθηκες» που κρατά μετά, ώστε να μη ξαναδίνεις κωδικό σε κάθε σελίδα.

Δηλαδή: κάνεις login μία φορά (authentication), και για την υπόλοιπη επίσκεψη το session cookie είναι που σε κρατά συνδεδεμένο. Αυτός είναι και ο λόγος που η προστασία του cookie είναι εξίσου κρίσιμη με την προστασία του κωδικού.

2.4 Οι σημαίες ασφαλείας των cookies

Ένα Set-Cookie μπορεί να συνοδεύεται από σημαίες (flags) που καθορίζουν πόσο ασφαλές είναι:

• HttpOnly: το cookie δεν είναι προσβάσιμο από JavaScript (document.cookie). Αποκόπτει την κλοπή cookie μέσω XSS (Cross-Site Scripting).
• Secure: το cookie στέλνεται μόνο μέσω HTTPS, ποτέ σε καθαρό (plaintext) HTTP. Εμποδίζει την υποκλοπή σε μη κρυπτογραφημένο δίκτυο.
• SameSite (Strict/Lax/None): ελέγχει αν το cookie στέλνεται σε αιτήματα από άλλους ιστότοπους — βασική άμυνα κατά του CSRF (Cross-Site Request Forgery).

Η απουσία αυτών των σημαιών είναι από τα πιο συχνά ευρήματα (findings) σε έναν έλεγχο ασφάλειας web εφαρμογής.

3. Πρακτικό κομμάτι: παρακολούθηση ενός session με curl

Θα χρησιμοποιήσουμε το curl, ένα εργαλείο γραμμής εντολών που μας δείχνει ακριβώς τι ταξιδεύει στο δίκτυο. Στόχος μας είναι μια απλή web εφαρμογή στο 10.10.10.20, μέσα στο απομονωμένο μας εργαστήριο. Θα δούμε ολόκληρο τον κύκλο ζωής ενός session: γέννηση, χρήση και προστασία.

3.1 Το session cookie γεννιέται στο login

Με τη σημαία -c (cookie jar) λέμε στο curl να αποθηκεύσει όποιο cookie λάβει σε ένα αρχείο. Στέλνουμε ένα POST με στοιχεία σύνδεσης προς το /login και παρατηρούμε την απόκριση. Το password είναι sanitised (…snip…) — ποτέ δεν καταγράφουμε πραγματικά credentials:

Ο server απαντά 302 Found και, το σημαντικό, στέλνει ένα Set-Cookie: session=…. Αυτή τη στιγμή γεννήθηκε το session: ο server δημιούργησε ένα τυχαίο session id και μας το έδωσε. Πρόσεξε ότι φέρει ήδη τη σημαία HttpOnly.

3.2 Τι αποθηκεύτηκε στο cookie jar

Ας κοιτάξουμε το αρχείο που έγραψε το -c. Το cookie jar του curl είναι απλό κείμενο και μας δείχνει καθαρά το session id μαζί με τα πεδία του:

Βλέπουμε το domain, το path, το πεδίο HttpOnly και την ίδια την τιμή του session. Αυτό το αρχείο είναι, ουσιαστικά, το «κλειδί» της συνεδρίας μας — γι’ αυτό και σε ένα πραγματικό σύστημα δεν πρέπει ποτέ να εκτίθεται.

3.3 Χρήση του cookie για πρόσβαση σε προστατευμένη σελίδα

Τώρα ζητάμε μια σελίδα που απαιτεί σύνδεση, το /dashboard. Πρώτα χωρίς cookie, μετά με το cookie μέσω της σημαίας -b (η οποία διαβάζει από το ίδιο jar). Η διαφορά στα status codes τα λέει όλα:

Χωρίς το cookie, ο server μας γυρίζει πίσω στο login (302). Με το session cookie, μας δίνει 200 OK και το περιεχόμενο. Δεν ξαναδώσαμε κωδικό — το cookie ήταν αρκετό. Αυτό ακριβώς κάνει το session hijacking τόσο επικίνδυνο: όποιος έχει το cookie, έχει την πρόσβαση.

3.4 Ασφαλές vs ευάλωτο cookie

Τέλος, συγκρίνουμε ένα σωστά ρυθμισμένο cookie (μέσω HTTPS) με ένα κακορυθμισμένο. Οι σημαίες κάνουν όλη τη διαφορά:

Το πρώτο cookie φέρει HttpOnly; Secure; SameSite=Strict — προστατευμένο από XSS, από υποκλοπή σε plaintext και από CSRF. Το δεύτερο, χωρίς καμία σημαία, είναι ένα κλασικό εύρημα σε αναφορά ασφάλειας. Ένας defender κοιτάζει αμέσως αυτές τις γραμμές.

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

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

• Ένα Kali Linux VM ως σταθμός εργασίας (ο client μας)·
• Ένα δεύτερο VM με μια απλή web εφαρμογή που έχει login (π.χ. DVWA ή ένα μικρό Flask/PHP app) στο 10.10.10.20, ως στόχος·
• Ένα host-only δίκτυο (VirtualBox/VMware) στο εύρος 10.10.10.0/24, ώστε η κίνηση να μη βγαίνει ποτέ έξω·
• Χρήση ουδέτερων διευθύνσεων (10.10.10.x) και sanitised output (…snip…) σε κάθε ευαίσθητη τιμή.

Έτσι μπορείς να πειραματιστείς ελεύθερα με cookies, session ids και σημαίες ασφαλείας χωρίς κανένα ρίσκο για τρίτους — και χωρίς να παραβιάζεις κανέναν νόμο.

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

Η παρακολούθηση cookies και sessions με εργαλεία όπως το curl είναι απολύτως νόμιμη μόνο σε συστήματα που σου ανήκουν ή για τα οποία έχεις ρητή, γραπτή εξουσιοδότηση (scope). Η υποκλοπή, η αναπαραγωγή (replay) ή η παραποίηση session cookies τρίτων συνιστά αδίκημα βάσει του ελληνικού και ευρωπαϊκού δικαίου (π.χ. Ν. 4411/2016 για την παράνομη πρόσβαση σε πληροφοριακά συστήματα, GDPR για τα προσωπικά δεδομένα, οδηγία NIS2).

Το πνεύμα αυτού του άρθρου είναι εκπαιδευτικό και αμυντικό: μαθαίνεις πώς λειτουργεί ο μηχανισμός ταυτοποίησης ώστε να προστατεύεις καλύτερα τις δικές σου εφαρμογές — σωστές σημαίες στα cookies, επιβολή HTTPS, μικρή διάρκεια ζωής και ανανέωση (rotation) των session ids, παρακολούθηση logs για ανώμαλα patterns. Δεν είναι οδηγός επίθεσης σε πραγματικό στόχο. Δούλευε πάντα μέσα στο δικό σου isolated lab.

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

• Το HTTP είναι stateless· τα cookies και τα sessions είναι ο μηχανισμός που κρατά τη συνέχεια μιας συνδεδεμένης συνεδρίας.
• Ο server δίνει το cookie με το header Set-Cookie και ο client το επιστρέφει με το header Cookie σε κάθε επόμενο request.
• Το session id είναι το «κλειδί» της συνεδρίας: πρέπει να είναι τυχαίο, μακρύ και απρόβλεπτο — αν κλαπεί, ισοδυναμεί με κλοπή πρόσβασης.
• Το authentication συμβαίνει μία φορά (login)· το session cookie είναι που σε κρατά συνδεδεμένο μετά.
• Οι σημαίες HttpOnly (κατά XSS), Secure (μόνο HTTPS) και SameSite (κατά CSRF) είναι υποχρεωτικές για ασφαλή cookies.
• Το curl με -c (αποθήκευση) και -b (χρήση) σου δείχνει ζωντανά όλον τον κύκλο ζωής ενός session.
• Εξάσκηση μόνο σε isolated lab ή σε συστήματα με εξουσιοδότηση — η γνώση εδώ είναι για άμυνα, όχι για επίθεση.

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