Code Injection σε εφαρμογές κινητών — τι είναι, είδη επιθέσεων και προστασία

Τι είναι το Code Injection;

Code Injection — μια κατηγορία επιθέσεων κατά την οποία ο επιτιθέμενος εισάγει εκτελέσιμο κώδικα στην εφαρμογή μέσω μη αξιόπιστων δεδομένων εισόδου. Σε εφαρμογές κινητών, η επίθεση είναι δυνατή μέσω πεδίων εισαγωγής, deep links, ειδοποιήσεων push, κωδικών QR και ανταλλαγής αρχείων.

Σε αντίθεση με επιθέσεις σε επίπεδο λειτουργικού συστήματος, το Code Injection εκμεταλλεύεται λογικά σφάλματα στον ίδιο τον κώδικα της εφαρμογής: έλλειψη διαφυγής, μη ασφαλή συνένωση συμβολοσειρών ή εμπιστοσύνη σε εξωτερικές πηγές δεδομένων. Σύμφωνα με την έκθεση της Positive Technologies (2025), οι ενέσεις αποτελούν το 23% όλων των τρωτών σημείων σε εφαρμογές κινητών του χρηματοπιστωτικού τομέα.

Ο κύριος κίνδυνος του Code Injection — πλήρης παραβίαση δεδομένων: ο επιτιθέμενος μπορεί να αποκτήσει πρόσβαση στη βάση δεδομένων, στο σύστημα αρχείων της συσκευής ή στους λογαριασμούς άλλων χρηστών. Για εφαρμογές κινητών που εργάζονται με δεδομένα πληρωμών ή ιατρικές πληροφορίες, οι συνέπειες μπορεί να είναι κρίσιμες.

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

Κύριοι τύποι Code Injection σε εφαρμογές κινητών

Η ταξινόμηση του Code Injection περιλαμβάνει τρεις κύριους τύπους επιθέσεων στο πλαίσιο της ανάπτυξης κινητών. Κάθε τύπος εκμεταλλεύεται διαφορετικά στοιχεία της εφαρμογής και απαιτεί συγκεκριμένες μεθόδους προστασίας.

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

SQL Injection (SQLi) — έγχυση κακόβουλου SQL κώδικα μέσω παραμέτρων ερωτημάτων σε τοπική ή απομακρυσμένη βάση δεδομένων. Σε εφαρμογές κινητών, η ευπάθεια εμφανίζεται κατά τη μη ασφαλή εργασία με SQLite στη συσκευή ή κατά τη δημιουργία αιτημάτων HTTP προς REST API με συνένωση συμβολοσειρών.

Το τυπικό διάνυσμα επίθεσης — ένα πεδίο αναζήτησης ή φιλτραρίσματος του οποίου η τιμή εισάγεται απευθείας στο ερώτημα SQL. Εάν ο προγραμματιστής χρησιμοποιεί ακατέργαστη συνένωση αντί για παραμετροποιημένα ερωτήματα, ο επιτιθέμενος μπορεί να στείλει μια συμβολοσειρά όπως 1' OR '1'='1. Σύμφωνα με το OWASP Mobile Top 10 (2024), το SQL Injection παραμένει το δεύτερο πιο συχνό κρίσιμο τρωτό σημείο σε εφαρμογές κινητών στην κατηγορία της μη ασφαλούς αποθήκευσης δεδομένων.

Η προστασία από SQLi βασίζεται σε τρία επίπεδα: χρήση παραμετροποιημένων ερωτημάτων (PreparedStatement σε Java, rawQuery με bindArgs σε Android), επικύρωση δεδομένων εισόδου από την πλευρά του πελάτη και του διακομιστή και ελάχιστα προνόμια βάσης δεδομένων.

Cross-Site Scripting (XSS) στο WebView

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

Δύο υποτύποι XSS διακρίνονται: Stored XSS — το κακόβουλο σενάριο αποθηκεύεται στον διακομιστή και εκτελείται σε κάθε προβολή σελίδας· Reflected XSS — ο κώδικας μεταδίδεται μέσω URL ή παραμέτρων POST και εκτελείται μία φορά. Σε εφαρμογές κινητών, το Stored XSS μέσω σχολίων, κριτικών ή περιεχομένου χρήστη που εμφανίζεται στο WebView σε άλλους χρήστες είναι ιδιαίτερα επικίνδυνο.

Η προστασία περιλαμβάνει απενεργοποίηση της JavaScript στο WebView εάν δεν απαιτείται, χρήση Πολιτικής Ασφάλειας Περιεχομένου (CSP) και απολύμανση περιεχομένου HTML μέσω βιβλιοθηκών όπως Jsoup για Android ή SwiftSoup για iOS.

Command Injection μέσω Intent και Shell

Command Injection — εκτέλεση εντολών συστήματος στη συσκευή μέσω μη προστατευμένων κλήσεων Runtime.exec(), ProcessBuilder ή NSTask. Σε εφαρμογές κινητών, η επίθεση είναι δυνατή εάν η εφαρμογή μεταβιβάζει δεδομένα χρήστη σε εντολές κελύφους ή Intent με ενέργειες.

Τα πιο ευάλωτα σημεία είναι οι λειτουργίες μετατροπής αρχείων, εργασίας με πολυμέσα (ffmpeg, ImageMagick) και εγκατάστασης εξωτερικών βιβλιοθηκών. Ο επιτιθέμενος μπορεί να στείλει μια εντολή με σύμβολο σωλήνωσης ή ανακατεύθυνσης που θα εκτελέσει αυθαίρετο κώδικα στη συσκευή. Το Android περιορίζει εν μέρει την πρόσβαση στο κέλυφος μέσω sandbox, αλλά εφαρμογές με πρόσβαση root ή εκμεταλλεύσεις PrivEsc μπορεί να παραβιαστούν.

Συνιστώμενη προστασία — πλήρης αποφυγή του Runtime.exec() για επεξεργασία δεδομένων χρήστη, χρήση βιβλιοθηκών με ασφαλές API και αυστηρή απομόνωση εξωτερικών διεργασιών.

Πώς λειτουργεί η έγχυση κώδικα σε Android και iOS

Ο μηχανισμός του Code Injection διαφέρει στις πλατφόρμες Android και iOS λόγω αρχιτεκτονικών διαφορών. Στο Android, οι ενέσεις συχνά σχετίζονται με το Intent — σύστημα μηνύματος που μεταδίδεται μεταξύ στοιχείων της εφαρμογής. Ο επιτιθέμενος μπορεί να στείλει κακόβουλο Intent με επιπλέον δεδομένα που περιέχουν κώδικα SQL ή εντολές κελύφους.

Στο iOS, οι επιθέσεις συμβαίνουν συχνότερα μέσω του μηχανισμού Interprocess Communication (XPC), Universal Links και επεξεργασίας URL Scheme. Μια εφαρμογή που δέχεται δεδομένα από εξωτερικές πηγές χωρίς έλεγχο γίνεται ευάλωτη σε ενέσεις. Σύμφωνα με το Apple Security Research (2025), περίπου το 12% των τρωτών σημείων σε εφαρμογές iOS σχετίζεται με ανεπαρκή απολύμανση δεδομένων εισόδου.

Κοινό διάνυσμα και για τις δύο πλατφόρμες — επίθεση μέσω τοπικής αποθήκευσης (SQLite, Realm, UserDefaults). Εάν μια κακόβουλη εφαρμογή μπορεί να γράψει δεδομένα σε έναν κοινόχρηστο κατάλογο, μπορεί να εισάγει κώδικα που θα εκτελεστεί από την εφαρμογή-στόχο κατά την ανάγνωση.

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

Παραδείγματα κώδικα: ευάλωτες και ασφαλείς υλοποιήσεις

Ας εξετάσουμε συγκεκριμένα παραδείγματα Code Injection σε Kotlin για Android και Swift για iOS. Κάθε παράδειγμα δείχνει ένα ευάλωτο μοτίβο και την ασφαλή εναλλακτική του.

SQL Injection: ευάλωτος κώδικας σε Kotlin

Το πρώτο παράδειγμα — άμεση συνένωση της συμβολοσειράς ερωτήματος με την είσοδο χρήστη. Στην τιμή userInput = "1' OR '1'='1", το ερώτημα θα επιστρέψει όλες τις γραμμές του πίνακα αντί για μία.

// ΕΥΑΛΩΤΟ: συνένωση συμβολοσειρών
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// ΑΣΦΑΛΕΣ: παραμετροποιημένο ερώτημα
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Προστασία XSS στο WebView: Swift για iOS

Το δεύτερο παράδειγμα δείχνει λανθασμένη και σωστή φόρτωση περιεχομένου HTML χρήστη στο WKWebView. Η χρήση του SwiftSoup επιτρέπει την αφαίρεση κακόβουλων σεναρίων πριν από την εμφάνιση.

// ΕΥΑΛΩΤΟ: άμεση φόρτωση HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// ΑΣΦΑΛΕΣ: απολύμανση μέσω SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: προστασία από επιθέσεις κελύφους σε Kotlin

Το τρίτο παράδειγμα — ο κίνδυνος κλήσης του Runtime.exec() με ορίσματα χρήστη και η ασφαλής εναλλακτική μέσω βιβλιοθήκης με σταθερό API.

// ΕΥΑΛΩΤΟ: εντολή shell με είσοδο χρήστη
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// ΑΣΦΑΛΕΣ: απομόνωση ορισμάτων
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Μέθοδοι προστασίας εφαρμογών κινητών από ενέσεις

Η προστασία από το Code Injection απαιτεί συστηματική προσέγγιση που καλύπτει τον κώδικα, την υποδομή και τις διαδικασίες ανάπτυξης. Κανένας μεμονωμένος μέθοδος δεν εγγυάται πλήρη ασφάλεια — απαιτείται συνδυασμός πρακτικών.

Πρώτο επίπεδο — πρόληψη: αυστηρή επικύρωση όλων των δεδομένων εισόδου. Κάθε πεδίο που λαμβάνει η εφαρμογή από τον χρήστη, άλλη εφαρμογή ή δίκτυο πρέπει να ελέγχεται για τύπο, μήκος και μορφή. Βιβλιοθήκες όπως το OWASP ESAPI παρέχουν έτοιμους επικυρωτές για κοινά σενάρια.

Δεύτερο επίπεδο — απολύμανση και διαφυγή: μετασχηματισμός δεδομένων πριν από τη χρήση τους σε ερωτήματα SQL, πρότυπα HTML ή εντολές κελύφους. Τα παραμετροποιημένα ερωτήματα εξαλείφουν πλήρως το SQL Injection και η διαφυγή HTML αποτρέπει το XSS. Στο Android, για εργασία με SQLite χρησιμοποιήστε το Room — ένα ORM που εφαρμόζει αυτόματα παραμέτρους bind.

Τρίτο επίπεδο — ελαχιστοποίηση προνομίων: η εφαρμογή πρέπει να λειτουργεί με τα ελάχιστα απαραίτητα δικαιώματα. Εφαρμόστε την αρχή του ελάχιστου προνομίου για τη βάση δεδομένων, το σύστημα αρχείων και την επικοινωνία μεταξύ διεργασιών. Το iOS υλοποιεί αυτήν την αρχή μέσω sandbox εφαρμογών και το Android — μέσω μοντέλου αδειών και απομόνωσης διεργασιών.

Τέταρτο επίπεδο — παρακολούθηση και απόκριση: καταγραφή ύποπτων λειτουργιών, ανίχνευση ανωμαλιών και αυτόματος αποκλεισμός σε επαναλαμβανόμενες επιθέσεις. Εργαλεία όπως το Firebase App Check βοηθούν στην ανίχνευση ψευδών αιτημάτων στο backend από παραβιασμένους πελάτες. Η ενσωμάτωση RASP (Runtime Application Self-Protection) επιτρέπει τον αποκλεισμό ενέσεων κατά τον χρόνο εκτέλεσης.

Σύμφωνα με έρευνα της Google Project Zero (2025), ο συνδυασμός αυτών των τεσσάρων επιπέδων μειώνει τον κίνδυνο επιτυχούς επίθεσης μέσω Code Injection κατά 94%. Οι προγραμματιστές συνιστάται να εφαρμόζουν μηχανισμούς προστασίας στο στάδιο σχεδιασμού της αρχιτεκτονικής, όχι μετά την ανακάλυψη τρωτού σημείου.