CSRF στην ανάπτυξη κινητών: ουσία, τύποι επιθέσεων και μέθοδοι προστασίας

Τι είναι η επίθεση CSRF;

CSRF (Cross-Site Request Forgery) είναι μια επίθεση κατά την οποία ο επιτιθέμενος δημιουργεί ένα πλαστό αίτημα και αναγκάζει το πρόγραμμα περιήγησης του θύματος να το στείλει στον στόχο εξυπηρετητή. Ο εξυπηρετητής εκτελεί το αίτημα διότι λαμβάνει έγκυρα cookie-credentials της τρέχουσας συνεργασίας του χρήστη. Η επίθεση είναι δυνατή επειδή το πρόγραμμα περιήγησης προσθέτει αυτόματα cookie σε κάθε αίτημα προς τον στόχο χώρο, ανεξάρτητα από τη σελίδα από την οποία στάλθηκε. Ο χρήστης μπορεί να μην έχει δει καν τη σελίδα του επιτιθέμενου — αρκεί η φόρτωση ενός κρυφού <img>, <form> ή <iframe> με κακόβουλο URL. Το CSRF δεν κλέβει απευθείας δεδομένα — η επίθεση εκτελεί ενέργειες εξ ονόματος του θύματος (λειτουργίες αλλαγής κατάστασης), όπως μεταφορά χρημάτων, αλλαγή κωδικού ή διαγραφή λογαριασμού.

Ποιες λειτουργίες είναι πιο επιρρεπείς;

Οι επιθέσεις CSRF στοχεύουν αποκλειστικά σε λειτουργίες που αλλάζουν την κατάσταση — αιτήματα GET με παρενέργειες, POST, PUT και DELETE. Για παράδειγμα, ένα αίτημα για αλλαγή διεύθυνσης email στον προσωπικό λογαριασμό: εάν ο εξυπηρετητής αποδέχεται το αίτημα χωρίς έλεγχο προέλευσης, ο επιτιθέμενος μπορεί να αντικαταστήσει το δικό του email και να ξεκινήσει επαναφορά κωδικού. Η επίθεση είναι ιδιαίτερα επικίνδυνη για τραπεζικά συστήματα, πίνακες διαχείρισης και κοινωνικά δίκτυα, όπου μία ενέργεια έχει σοβαρές συνέπειες. Τα API εφαρμογών κινητών που χρησιμοποιούν cookie για ταυτοποίηση είναι επίσης επιρρεπή σε CSRF εάν δεν εφαρμόζουν επιπλέον ελέγχους.

Ποιος κινδυνεύει;

Οποιαδήποτε εφαρμογή web ή API όπου η ταυτοποίηση βασίζεται σε cookie και ο εξυπηρετητής δεν ελέγχει την προέλευση του αιτήματος, κινδυνεύει από επίθεση. Οι εφαρμογές κινητών που χρησιμοποιούν WebView για εξουσιοδότηση μέσω φορμών web είναι επίσης ευάλωτες: το συστατικό του προγράμματος περιήγησης στέλνει αυτόματα cookie, και ο επιτιθέμενος μπορεί να εισάγει κακόβουλο αίτημα μέσω φόρτωσης στο παρασκήνιο. Σύμφωνα με το HackerOne (2025), περίπου 12% όλων των αναφορών ευπαθειών σε εφαρμογές web σχετίζονται με την έλλειψη προστασίας CSRF.

Τι κάνει το CSRF επικίνδυνο;

Το κύριο χαρακτηριστικό του CSRF είναι η απερατότητά του για το θύμα. Ο χρήστης μπορεί να μην υποψιάζεται καν ότι η επίθεση έλαβε χώρα: το πλαστό αίτημα εκτελείται στο παρασκήνιο, και η διεπαφή της εφαρμογής δεν εμφανίζει σημάδια εισβολής. Ο μόνος τρόπος εντοπισμού CSRF είναι η παρακολούθηση των αρχείων καταγραφής του εξυπηρετητή ή ξαφνικές αλλαγές στον λογαριασμό. Επιπλέον, το CSRF συνδυάζεται εύκολα με άλλες ευπάθειες, όπως XSS ή ανοικτές ανακατευθύνσεις, πολλαπλασιάζοντας τη ζημιά.

Πώς λειτουργεί η επίθεση CSRF;

Η επίθεση CSRF αποτελείται από τρεις υποχρεωτικές συνθήκες: το θύμα είναι εξουσιοδοτημένο στον στόχο ιστότοπο, ο εξυπηρετητής χρησιμοποιεί ταυτοποίηση με cookie, και το αίτημα του επιτιθέμενου κατευθύνεται στο URL της ενέργειας. Ο επιτιθέμενος δημιουργεί μια σελίδα HTML με ένα φόρμα, σκριπτ ή εικόνα της οποίας το χαρακτηριστικό src δείχνει στο URL στόχο. Το πρόγραμμα περιήγησης του θύματος φορτώνει αυτή τη σελίδα και στέλνει αυτόματα το αίτημα στον εξυπηρετητή μαζί με το cookie της τρέχουσας συνεργασίας. Ο εξυπηρετητής λαμβάνει έγκυρα cookie, δεν ελέγχει την πηγή του αιτήματος και εκτελεί τη λειτουργία.

<!-- Παράδειγμα επίθεσης CSRF μέσω κρυφής φόρμας -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Μετά τη φόρτωση της σελίδας, το σκριπτ στέλνει αμέσως το φόρμα. Το πρόγραμμα περιήγησης προσαρτά το cookie συνεργασίας του χρήστη στο αίτημα POST προς bank.example.com. Ο εξυπηρετητής της τράπεζας ελέγχει το cookie, επιβεβαιώνει ότι ο χρήστης είναι ταυτοποιημένος και εκτελεί τη μεταφορά στον λογαριασμό του επιτιθέμενου. Το θύμα βλέπει μια άδεια ή νόμιμη σελίδα, και τα χρήματα έχουν ήδη χρεωθεί.

Ο ρόλος του προγράμματος περιήγησης στο CSRF

Το κύριο χαρακτηριστικό του πρωτοκόλλου HTTP — η απουσία ενσωματωμένου ελέγχου προέλευσης του αιτήματος. Το πρόγραμμα περιήγησης προσθέτει το cookie στο αίτημα εάν το όνομα χώρου του αιτήματος συμπίπτει με το όνομα χώρου του cookie. Ο επιτιθέμενος δεν χρειάζεται να γνωρίζει το περιεχόμενο του cookie — το πρόγραμμα περιήγησης το κάνει αυτόματα. Το Same-origin policy δεν προστατεύει από CSRF επειδή η επίθεση στοχεύει στον εξυπηρετητή, όχι στην ανάγνωση της απάντησης. Μηχανισμοί όπως το CORS είναι επίσης ανίσχυροι: τα αιτήματα CSRF συνήθως δεν απαιτούν ανάγνωση της απάντησης για να προκαλέσουν ζημιά.

Κύριοι τύποι επιθέσεων CSRF

Οι επιθέσεις CSRF ταξινομούνται με βάση τον τρόπο παράδοσης του κακόβουλου αιτήματος. Κάθε τύπος χρησιμοποιεί διαφορετικό HTML στοιχείο για να στείλει το αίτημα, αλλά όλοι βασίζονται στην αυτόματη αποστολή cookie από το πρόγραμμα περιήγησης. Η επιλογή της μεθόδου εξαρτάται από τους στόχους του επιτιθέμενου: οι επιθέσεις GET-based απαιτούν λιγότερο κώδικα, οι POST-based παρακάμπτουν πιο αξιόπιστα κάποιες προστασίες, και οι XMLHttpRequest-based επιτρέπουν χειρισμό των κεφαλίδων.

GET-based CSRF

Η πιο απλή μέθοδος: ο επιτιθέμενος τοποθετεί ένα <img> στη σελίδα με URL που περιέχει τις παραμέτρους του αιτήματος. Το πρόγραμμα περιήγησης φορτώνει την εικόνα και στέλνει ένα αίτημα GET στον εξυπηρετητή. Για παράδειγμα, <img src="https://api.example.com/delete?postId=123" /> διαγράφει την εγγραφή εάν ο εξυπηρετητής επεξεργάζεται το DELETE μέσω GET. Παρά τον προφανή κίνδυνο, ορισμένα API ακόμα χρησιμοποιούν GET για λειτουργίες διαγραφής ή ενημέρωσης.

POST-based CSRF

Εάν ο εξυπηρετητής δέχεται μόνο αιτήματα POST, ο επιτιθέμενος δημιουργεί ένα κρυφό φόρμα με μέθοδο POST και το στέλνει αυτόματα μέσω JavaScript. Το φόρμα δεν εμφανίζεται στην οθόνη (όλα τα <input> έχουν type="hidden"), και το autofocus + .submit() λειτουργεί χωρίς κλικ του χρήστη. Οι επιθέσεις POST-based δεν λειτουργούν εάν ο εξυπηρετητής ελέγχει την κεφαλίδα Content-Type, αλλά τα περισσότερα API αποδέχονται την τυπική application/x-www-form-urlencoded.

XHR-based CSRF (με CORS)

Το XMLHttpRequest ή Fetch API επιτρέπουν αποστολή αιτημάτων με αυθαίρετες κεφαλίδες. Εάν ο εξυπηρετητής έχει ρυθμίσει το CORS πολύ ευρέως (Access-Control-Allow-Origin: *), ο επιτιθέμενος μπορεί να στείλει οποιοδήποτε αίτημα και να διαβάσει την απάντηση. Ωστόσο, για μια επίθεση CSRF η ανάγνωση της απάντησης δεν είναι απαραίτητη — αρκεί η εκτέλεση της ενέργειας. Τα σύγχρονα προγράμματα περιήγησης στέλνουν ένα αίτημα preflight OPTIONS πριν από μη τυπικά αιτήματα, που μπορεί να μπλοκάρει το XHR-based CSRF εάν ο εξυπηρετητής είναι σωστά ρυθμισμένος.

CSRF σε εφαρμογές κινητών

Οι εφαρμογές κινητών είναι λιγότερο επιρρεπείς σε CSRF από τις ιστοσελίδες, επειδή οι εγγενείς εφαρμογές σπάνια χρησιμοποιούν ταυτοποίηση με cookie. Αντ' αυτού, τα κινητά API συχνότερα εφαρμόζουν token στην κεφαλίδα Authorization (Bearer token, JWT). Υπάρχουν όμως σενάρια όπου μια επίθεση CSRF είναι δυνατή: WebView με σύνδεση web, υβριδικές εφαρμογές και API με συνεδρίες βασισμένες σε cookie. Σύμφωνα με το TechCrunch (2025), περίπου 18% των δημόσιων API κινητών εφαρμογών ακόμα υποστηρίζουν cookie συνεδρίας.

CSRF μέσω WebView

Πολλές εφαρμογές ανοίγουν ιστοσελίδες σε WebView — εξουσιοδότηση μέσω OAuth, φόρμες πληρωμής, προβολή περιεχομένου. Το WebView είναι ένα πλήρες πρόγραμμα περιήγησης μέσα στην εφαρμογή που αποθηκεύει cookie συνεδρίας. Εάν ο επιτιθέμενος βρει έναν τρόπο να φορτώσει το δικό του URL στο WebView (μέσω ανοικτής ανακατεύθυνσης ή Deep Link), μπορεί να εκτελέσει επίθεση CSRF ακριβώς όπως σε ένα κανονικό πρόγραμμα περιήγησης. Προστασία — χρήση Chrome Custom Tabs ή SFSafariViewController αντί για WebView για κρίσιμες λειτουργίες.

CSRF σε API με ταυτοποίηση JWT

Τα token JWT συνήθως αποθηκεύονται στο localStorage ή στη μνήμη της εφαρμογής και δεν αποστέλλονται αυτόματα — ο προγραμματιστής προσθέτει ρητά την κεφαλίδα Authorization σε κάθε αίτημα. Αυτό καθιστά την κλασική επίθεση CSRF αδύνατη. Ωστόσο, εάν η εφαρμογή αποθηκεύει JWT σε cookie (σπάνιο αλλά συμβαίνει), ο κίνδυνος επιστρέφει. Επιπλέον προστασία — σύνδεση του JWT με μια συγκεκριμένη προέλευση αιτήματος μέσω του azp ή aud claim, που αποτρέπει τη χρήση του token σε άλλο χώρο.

// Παράδειγμα επαλήθευσης token CSRF από την πλευρά του διακομιστή στο Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Δημιουργία token CSRF κατά τη σύνδεση
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Μέθοδοι προστασίας από CSRF

Η σύγχρονη προστασία από CSRF βασίζεται σε τρία επίπεδα: server-side CSRF token, το χαρακτηριστικό SameSite για cookie και έλεγχο της κεφαλίδας Origin. Ο συνδυασμός αυτών των μεθόδων παρέχει προστασία από 99% των επιθέσεων CSRF χωρίς σημαντική επίδραση στην εμπειρία χρήστη. Η επιλογή της συγκεκριμένης προσέγγισης εξαρτάται από την αρχιτεκτονική της εφαρμογής: μια ιστοσελίδα μπορεί να χρησιμοποιήσει SameSite=Lax, το API μιας κινητής εφαρμογής απαιτεί token στις κεφαλίδες.

CSRF token (συγχρονιστής)

Τυπική μέθοδος: ο εξυπηρετητής δημιουργεί ένα μοναδικό token, το συνδέει με τη συνεδρία του χρήστη και το μεταδίδει στον πελάτη. Ο πελάτης περιλαμβάνει το token σε κάθε αίτημα που αλλάζει κατάσταση (στο κρυφό πεδίο του φόρμα ή στην κεφαλίδα X-CSRF-Token). Ο εξυπηρετητής συγκρίνει το ληφθέν token με αυτό που είναι αποθηκευμένο στη συνεδρία. Το token πρέπει να είναι κρυπτογραφικά ασφαλές, τυχαίο, μήκους τουλάχιστον 32 byte και να αλλάζει σε κάθε συνεδρία ή λειτουργία. Η διάρκεια ζωής του token — όχι περισσότερο από μερικές ώρες.

SameSite Cookie

Το χαρακτηριστικό SameSite για cookie περιορίζει την αποστολή cookie σε διαφορετικά ονοματικά χώρου. Η τιμή Lax επιτρέπει την αποστολή cookie μόνο για πλοηγητικά αιτήματα GET ανώτατου επιπέδου — αυτό είναι αρκετό για τις περισσότερες ιστοσελίδες. Το Strict μπλοκάρει τα cookie για όλα τα αιτήματα διαφορετικού χώρου, συμπεριλαμβανομένης της πλοήγησης: ο χρήστης θα πρέπει να συνδεθεί ξανά κατά τη μετάβαση από άλλη ιστοσελίδα. Σύμφωνα με το Chrome Platform Status (2026), το SameSite=Lax είναι ενεργοποιημένο από προεπιλογή σε όλα τα σύγχρονα προγράμματα περιήγησης, μειώνοντας τον αριθμό επιθέσεων CSRF κατά 67%.

Έλεγχος Origin και Referer

Ο εξυπηρετητής μπορεί να ελέγχει τις κεφαλίδες Origin ή Referer του εισερχόμενου αιτήματος. Εάν το αίτημα προέρχεται από άλλο χώρο — μπλοκάρεται. Το Origin είναι πιο αξιόπιστο από το Referer, επειδή είναι πάντα παρόν σε αιτήματα POST και δεν απενεργοποιείται από πολιτικές προγράμματος περιήγησης. Υλοποίηση: λευκή λίστα επιτρεπόμενων origin, σύγκριση με την τρέχουσα τιμή της κεφαλίδας. Η μέθοδος είναι αποτελεσματική αλλά περίπλοκη με κινητές εφαρμογές όπου οι κεφαλίδες Origin μπορεί να απουσιάζουν ή να παραποιούνται.

// Παράδειγμα επαλήθευσης token CSRF στο Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Μια μέθοδος που δεν απαιτεί αποθήκευση token στον εξυπηρετητή: ο εξυπηρετητής ορίζει ένα cookie με τυχαία τιμή, ο πελάτης διαβάζει την τιμή από το cookie και την στέλνει πίσω στην κεφαλίδα ή στο σώμα του αιτήματος. Ο εξυπηρετητής συγκρίνει και τις δύο τιμές. Εάν ο επιτιθέμενος δεν μπορεί να διαβάσει το cookie (Same-origin policy), δεν θα μπορέσει να παραποιήσει το token. Η μέθοδος είναι πιο εύκολη στην υλοποίηση από τον συγχρονιστή, αλλά απαιτεί HTTPS για προστασία του cookie από υποκλοπή.

• CSRF token — το χρυσό πρότυπο: αξιόπιστο, δοκιμασμένο, υποστηρίζεται από όλα τα frameworks
• SameSite=Lax — ελάχιστη προστασία για web εφαρμογές: δωρεάν, αυτόματη, δεν απαιτεί κώδικα
• Έλεγχος Origin — επιπλέον επίπεδο: μπλοκάρει επιθέσεις πριν τον έλεγχο του token
• Double Submit — για REST API χωρίς server-side συνεδρίες: αποτελεσματικό σε HTTPS
• Προσαρμοσμένες κεφαλίδες — X-Requested-With: XMLHttpRequest μπλοκάρει απλά φόρμες CSRF

Διαφορά μεταξύ CSRF και XSS

CSRF και XSS είναι διαφορετικοί τύποι επιθέσεων που συχνά συγχέονται. Το CSRF εκμεταλλεύεται την εμπιστοσύνη του εξυπηρετητή στο πρόγραμμα περιήγησης του χρήστη: ο εξυπηρετητής εκτελεί την εντολή του επιτιθέμενου επειδή το αίτημα έρχεται με έγκυρα cookie. Το XSS εκμεταλλεύεται την εμπιστοσύνη του προγράμματος περιήγησης στο περιεχόμενο του εξυπηρετητή: το πρόγραμμα περιήγησης εκτελεί το σκριπτ που έχει εισάγει ο επιτιθέμενος στη σελίδα. Το CSRF δεν απαιτεί εισαγωγή κώδικα στον στόχο ιστότοπο — αρκεί η αποστολή αιτήματος από άλλο χώρο. Το XSS, αντίθετα, απαιτεί την εύρεση τρόπου εισαγωγής του δικού του JavaScript στον HTML κώδικα της σελίδας. Επιπλέον, το XSS μπορεί να παρακάμψει την προστασία CSRF: το εισαγόμενο σκριπτ διαβάζει το CSRF token από τη σελίδα και το στέλνει μαζί με το αίτημα.

Η κατανόηση της διαφοράς μεταξύ CSRF και XSS είναι κρίσιμη για την οικοδόμηση πολυεπίπεδης προστασίας. Τα CSRF token δεν προστατεύουν από XSS, και το CSP (Content Security Policy) δεν προστατεύει από CSRF. Μόνο ο συνδυασμός μεθόδων εξασφαλίζει την ασφάλεια της εφαρμογής και από τους δύο τύπους επιθέσεων. Σε κινητές εφαρμογές με WebView οι κίνδυνοι διπλασιάζονται, γι' αυτό οι προγραμματιστές συνιστάται να εφαρμόζουν τουλάχιστον CSRF token για αιτήματα API και Content Security Policy για περιεχόμενο web.