Ασφάλεια Sessions, Cookies, Tokens και Πρόληψη Session Hijacking — DedSec Project

Μετά την επιτυχημένη αυθεντικοποίηση, μια εφαρμογή πρέπει να διατηρεί την ταυτότητα του χρήστη με ασφάλεια. Session cookies, bearer tokens, refresh tokens και device sessions γίνονται ουσιαστικά credentials: όποιος αποκτήσει έγκυρη τιμή μπορεί συχνά να ενεργήσει ως ο χρήστης μέχρι να λήξει ή να ανακληθεί.

Όριο εξουσιοδότησης: Δοκίμαζε session behavior μόνο σε εφαρμογές και λογαριασμούς που σου ανήκουν ή είναι ρητά εντός scope. Χρησιμοποίησε synthetic accounts και δεδομένα· μην συλλέγεις ή επαναχρησιμοποιείς sessions άλλων χρηστών.

Μαθησιακοί στόχοι

• Να ξεχωρίζεις authentication από session management.
• Να κατανοείς session IDs, cookies, access/refresh tokens και expiration.
• Να ελέγχεις Secure, HttpOnly, SameSite, scope και rotation.
• Να αξιολογείς logout, password reset και server-side revocation.
• Να εντοπίζεις authorization λάθη που παραμένουν ακόμη με ασφαλή tokens.

Session lifecycle

Ένα session έχει δημιουργία, χρήση, ανανέωση, πιθανή rotation, λήξη και ανάκληση. Η εφαρμογή πρέπει να αποφεύγει predictable identifiers και να μην κρατά sessions ενεργά επ' αόριστον. Η αλλαγή password, account disable ή κρίσιμη αλλαγή ασφάλειας πρέπει να έχει σαφή επίδραση στα υπάρχοντα sessions.

Cookies

Το Secure περιορίζει cookie transmission σε HTTPS, το HttpOnly δυσκολεύει πρόσβαση μέσω JavaScript και το SameSite επηρεάζει cross-site αποστολή. Τα Domain και Path πρέπει να είναι όσο πιο στενά γίνεται. Αυτά είναι σημαντικά controls, αλλά δεν αντικαθιστούν σωστό authorization ή XSS prevention.

Bearer και refresh tokens

Ένα bearer token παρέχει πρόσβαση σε όποιον το κατέχει. Για αυτό χρειάζονται μικρό lifetime, σωστό audience/scope, ασφαλής αποθήκευση και ανάκληση όπου απαιτείται. Τα refresh tokens έχουν μεγαλύτερη αξία και πρέπει να προστατεύονται ακόμη περισσότερο, συχνά με rotation και reuse detection.

Session fixation και rotation

Η εφαρμογή δεν πρέπει να διατηρεί attacker-controlled ή προ-authentication identifier μετά το login. Ένα νέο authentication event ή privilege change είναι καλό σημείο για rotation του session identifier.

Logout και revocation

Ένα κουμπί logout που απλώς διαγράφει local UI state δεν είναι αρκετό όταν το server-side credential παραμένει ενεργό. Έλεγξε τι συμβαίνει σε logout, password reset, MFA reset, account disable, device removal και admin revocation.

Authorization παραμένει ξεχωριστό

Ένα έγκυρο session αποδεικνύει ποιος είναι ο caller, όχι ότι επιτρέπεται να δει οποιοδήποτε object. Κάθε server-side operation πρέπει να εφαρμόζει authorization στον τρέχοντα user/tenant/object/action συνδυασμό.

Detection

Χρήσιμα signals περιλαμβάνουν νέα device/location, ασυνήθιστη αλλαγή privilege, token reuse μετά από rotation, session χρήση μετά από logout/revocation και απότομες αλλαγές σε refresh behavior. Τα signals πρέπει να αξιολογούνται με context ώστε να περιορίζονται false positives.

Καθοδηγούμενο εργαστήριο

Σε δική σου demo εφαρμογή ή training lab, δημιούργησε δύο synthetic users. Κατέγραψε ποια cookies/tokens δημιουργούνται, πότε λήγουν, τι flags έχουν και τι συμβαίνει μετά από logout ή password change. Επιβεβαίωσε ότι ο User A δεν μπορεί να προσπελάσει test object του User B αλλάζοντας μόνο identifier.

Συνηθισμένα λάθη

• Πολύ μεγάλα token lifetimes.
• Refresh tokens χωρίς rotation ή revocation plan.
• Cookies με υπερβολικά ευρύ Domain/Path.
• Logout μόνο στην πλευρά του browser.
• Υπόθεση ότι authentication σημαίνει authorization.
• Logging ολόκληρων session tokens.

Έλεγχος γνώσεων

1. Γιατί ένα session token αντιμετωπίζεται σαν credential;
2. Τι προστατεύει το HttpOnly και τι δεν προστατεύει;
3. Γιατί χρειάζεται rotation μετά από authentication/privilege change;
4. Τι πρέπει να συμβεί στα sessions μετά από account disable;
5. Γιατί authorization απαιτείται σε κάθε object access;

Καθοδηγούμενη μελέτη

Χρησιμοποίησε τη Μεθοδολογία Μελέτης. Δούλεψε μόνο με synthetic accounts και κατέγραψε lifecycle, όχι πραγματικά credentials.

Συνέχισε με

Προτεινόμενα επόμενα modules: 14, 22, 39, 70, 71, 131.