CSRF σε portals και admin panels: γιατί οι φόρμες χρειάζονται προστασία πέρα από το login

Σε ένα customer portal, CRM ή admin panel, ο χρήστης μπορεί να κάνει κρίσιμες ενέργειες: να αλλάξει email, να ενημερώσει ρόλους, να διαγράψει αρχείο, να εγκρίνει αίτημα ή να αποστείλει δεδομένα σε τρίτο σύστημα.

Το γεγονός ότι ο χρήστης είναι logged in δεν αρκεί. Αν η εφαρμογή δεν προστατεύει σωστά τις state-changing ενέργειες, μπορεί να υπάρχει ρίσκο CSRF, δηλαδή Cross-Site Request Forgery.

Τι είναι CSRF

CSRF είναι επίθεση όπου ένας authenticated χρήστης παρασύρεται να στείλει request σε εφαρμογή όπου είναι ήδη συνδεδεμένος. Ο browser στέλνει cookies αυτόματα, άρα το σύστημα μπορεί να θεωρήσει ότι η ενέργεια είναι νόμιμη.

Το πρόβλημα εμφανίζεται κυρίως σε actions που αλλάζουν κατάσταση:

• αλλαγή password ή email
• αλλαγή permissions
• διαγραφή εγγραφής
• αποστολή φόρμας
• έγκριση πληρωμής ή αιτήματος
• αλλαγή ρυθμίσεων account

CSRF tokens

Η κλασική άμυνα είναι CSRF token. Η εφαρμογή δημιουργεί token που πρέπει να σταλεί μαζί με τη φόρμα ή το request. Ένα τρίτο site δεν μπορεί εύκολα να γνωρίζει αυτό το token.

Σημαντικά σημεία:

• το token πρέπει να είναι μοναδικό και μη προβλέψιμο
• πρέπει να ελέγχεται server-side
• δεν πρέπει να μπαίνει σε logs
• πρέπει να συνδέεται με session ή action όπου χρειάζεται

SameSite cookies

Τα SameSite cookies μειώνουν το ρίσκο επειδή περιορίζουν πότε ο browser στέλνει cookies σε cross-site requests. Δεν αντικαθιστούν πάντα τα CSRF tokens, αλλά είναι σημαντική γραμμή άμυνας.

Για πολλά portals, ένα σωστό setup περιλαμβάνει HttpOnly, Secure και SameSite cookies, μαζί με CSRF προστασία σε state-changing actions.

APIs και SPAs

Σε Single Page Applications, το CSRF εξαρτάται από το πώς γίνεται authentication. Αν χρησιμοποιούνται cookies για auth, χρειάζεται CSRF σκέψη. Αν χρησιμοποιούνται bearer tokens σε headers, το ρίσκο μεταφέρεται κυρίως στη σωστή αποθήκευση και προστασία του token.

Δεν υπάρχει μία λύση για όλα. Η αρχιτεκτονική authentication καθορίζει και την προστασία.

Κρίσιμες ενέργειες

Για υψηλού ρίσκου actions, μπορεί να χρειάζεται επιπλέον re-authentication ή επιβεβαίωση.

Παραδείγματα:

• αλλαγή email λογαριασμού
• αλλαγή ρόλου χρήστη
• διαγραφή μεγάλης ποσότητας δεδομένων
• σύνδεση νέου payment provider
• εξαγωγή ευαίσθητων αρχείων

Η προστασία πρέπει να ταιριάζει στο ρίσκο της ενέργειας.

Πώς το κάνει η Ai Foundry

Στην Ai Foundry σχεδιάζουμε portals, CRM και custom web applications με ασφάλεια στις πραγματικές ροές εργασίας. Δεν αρκούμαστε στο login. Ελέγχουμε ποιες ενέργειες αλλάζουν δεδομένα, ποια requests χρειάζονται CSRF προστασία, πώς ρυθμίζονται τα cookies και πότε απαιτείται επιπλέον επιβεβαίωση.

Αυτό είναι κρίσιμο σε εφαρμογές με πελάτες, αρχεία, approvals, πληρωμές ή admin users. Η σωστή προστασία μειώνει ρίσκο χωρίς να κάνει το interface δύσχρηστο.

Checklist

Ελέγξτε:

• ποιες ενέργειες αλλάζουν δεδομένα
• αν όλες οι φόρμες προστατεύονται server-side
• αν χρησιμοποιούνται CSRF tokens όπου χρειάζεται
• αν τα cookies έχουν Secure, HttpOnly και SameSite ρυθμίσεις
• αν κρίσιμες αλλαγές απαιτούν re-authentication
• αν APIs και frontend auth έχουν συνεπή μοντέλο προστασίας
• αν αποφεύγεται state change με απλό GET request
• αν τα security events καταγράφονται χωρίς secrets

Το CSRF είναι παράδειγμα προβλήματος που δεν φαίνεται στο UI. Φαίνεται όταν μια κρίσιμη ενέργεια μπορεί να εκτελεστεί χωρίς πραγματική πρόθεση του χρήστη.