Code Injection în aplicațiile mobile — ce este, tipuri de atacuri și protecție

Ce este Code Injection?

Code Injection — o clasă de atacuri în care atacatorul injectează cod executabil în aplicație prin date de intrare nesigure. În aplicațiile mobile, atacul este posibil prin câmpuri de introducere, deep link-uri, notificări push, coduri QR și schimb de fișiere.

Spre deosebire de atacurile la nivel de sistem de operare, Code Injection exploatează erori logice în codul aplicației însăși: lipsa escapării, concatenarea nesigură a șirurilor sau încrederea în surse externe de date. Conform raportului Positive Technologies (2025), injecțiile reprezintă 23% din toate vulnerabilitățile din aplicațiile mobile ale sectorului financiar.

Principalul pericol al Code Injection — compromiterea completă a datelor: atacatorul poate obține acces la baza de date, sistemul de fișiere al dispozitivului sau conturile altor utilizatori. Pentru aplicațiile mobile care lucrează cu date de plată sau informații medicale, consecințele pot fi critice.

Dezvoltatorul trebuie să înțeleagă tipurile de injecții și să aplice mecanisme de protecție la toate nivelurile — de la introducerea datelor până la afișarea și stocarea acestora. Framework-urile moderne oferă instrumente de protecție încorporate, dar utilizarea lor necesită o abordare conștientă.

Principalele tipuri de Code Injection în aplicațiile mobile

Clasificarea Code Injection include trei tipuri principale de atacuri în contextul dezvoltării mobile. Fiecare tip exploatează componente diferite ale aplicației și necesită metode specifice de protecție.

SQL Injection în aplicațiile mobile

SQL Injection (SQLi) — injectarea codului SQL malițios prin parametrii interogărilor către baza de date locală sau la distanță. În aplicațiile mobile, vulnerabilitatea apare la lucrul nesigur cu SQLite pe dispozitiv sau la construirea cererilor HTTP către REST API cu concatenare de șiruri.

Vectorul tipic de atac — câmpul de căutare sau filtrare a cărui valoare este introdusă direct în interogarea SQL. Dacă dezvoltatorul folosește concatenarea directă în loc de interogări parametrizate, atacatorul poate transmite un șir precum 1' OR '1'='1. Conform OWASP Mobile Top 10 (2024), SQL Injection rămâne a doua cea mai frecventă vulnerabilitate critică în aplicațiile mobile în categoria stocării nesigure a datelor.

Protecția împotriva SQLi se bazează pe trei niveluri: utilizarea interogărilor parametrizate (PreparedStatement în Java, rawQuery cu bindArgs în Android), validarea datelor de intrare pe partea clientului și serverului și privilegii minime ale bazei de date.

Cross-Site Scripting (XSS) în WebView

Atacurile XSS în aplicațiile mobile vizează componenta WebView — browserul încorporat care afișează conținut HTML. Dacă aplicația încarcă în WebView date din surse externe fără sanitizare, atacatorul poate injecta cod JavaScript care se va executa în contextul aplicației.

Se disting două subtipuri de XSS: Stored XSS — scriptul malițios este stocat pe server și se execută la fiecare vizualizare a paginii; Reflected XSS — codul este transmis prin URL sau parametri POST și se execută o singură dată. În aplicațiile mobile, Stored XSS prin comentarii, recenzii sau conținut utilizator afișat în WebView altor utilizatori este deosebit de periculos.

Protecția include dezactivarea JavaScript în WebView dacă nu este necesar, utilizarea Content Security Policy (CSP) și sanitizarea conținutului HTML prin biblioteci precum Jsoup pentru Android sau SwiftSoup pentru iOS.

Command Injection prin Intent și Shell

Command Injection — executarea comenzilor de sistem pe dispozitiv prin apeluri neprotejate Runtime.exec(), ProcessBuilder sau NSTask. În aplicațiile mobile, atacul este posibil dacă aplicația transmite datele utilizatorului către comenzi shell sau Intent-uri cu acțiuni.

Cele mai vulnerabile locuri sunt funcțiile de conversie a fișierelor, lucrul cu media (ffmpeg, ImageMagick) și instalarea bibliotecilor externe. Atacatorul poate transmite o comandă cu simbol de conductă sau redirecționare care va executa cod arbitrar pe dispozitiv. Android limitează parțial accesul shell prin sandbox, dar aplicațiile cu acces root sau exploit-uri PrivEsc pot fi compromise.

Protecția recomandată — renunțarea completă la Runtime.exec() pentru procesarea datelor utilizatorului, utilizarea bibliotecilor cu API securizat și izolarea strictă a proceselor externe.

Cum funcționează injectarea codului pe Android și iOS

Mecanismul Code Injection diferă pe platformele Android și iOS din cauza diferențelor arhitecturale. Pe Android, injecțiile sunt adesea legate de Intent — mesajul sistemului transmis între componentele aplicației. Atacatorul poate trimite un Intent malițios cu date extra conținând cod SQL sau comenzi shell.

Pe iOS, atacurile au loc mai frecvent prin mecanismul Interprocess Communication (XPC), Universal Links și procesarea URL Scheme. O aplicație care primește date din surse externe fără verificare devine vulnerabilă la injecții. Conform Apple Security Research (2025), aproximativ 12% din vulnerabilitățile aplicațiilor iOS sunt legate de sanitizarea insuficientă a datelor de intrare.

Vectorul comun pentru ambele platforme — atacul prin stocarea locală (SQLite, Realm, UserDefaults). Dacă o aplicație malițioasă poate scrie date într-un director partajat, poate injecta cod care va fi executat de aplicația țintă la citire.

Procesul unui atac tipic include trei etape: recunoaștere — analiza punctelor de intrare ale aplicației (formulare, deep link-uri, fișiere), injectare — transmiterea încărcăturii malițioase prin punctul de intrare găsit și exploatare — executarea injecției cu obținerea accesului la date sau funcționalități. Înțelegerea acestui ciclu ajută dezvoltatorul să proiecteze protecția la fiecare etapă.

Exemple de cod: implementări vulnerabile și sigure

Să examinăm exemple concrete de Code Injection în Kotlin pentru Android și Swift pentru iOS. Fiecare exemplu arată un model vulnerabil și alternativa sa sigură.

SQL Injection: cod vulnerabil în Kotlin

Primul exemplu — concatenarea directă a șirului interogării cu datele de intrare ale utilizatorului. La valoarea userInput = "1' OR '1'='1", interogarea va returna toate rândurile tabelului în loc de unul singur.

// VULNERABIL: concatenare de șiruri
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// SIGUR: interogare parametrizată
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Protecția XSS în WebView: Swift pentru iOS

Al doilea exemplu demonstrează încărcarea incorectă și corectă a conținutului HTML al utilizatorului în WKWebView. Utilizarea SwiftSoup permite eliminarea scripturilor malițioase înainte de afișare.

// VULNERABIL: încărcare directă HTML
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SIGUR: sanitizare prin SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: protecția împotriva atacurilor shell în Kotlin

Al treilea exemplu — pericolul apelării Runtime.exec() cu argumente de la utilizator și alternativa sigură printr-o bibliotecă cu API fix.

// VULNERABIL: comandă shell cu intrare utilizator
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SIGUR: izolare argumente
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metode de protecție a aplicațiilor mobile împotriva injecțiilor

Protecția împotriva Code Injection necesită o abordare sistematică ce acoperă codul, infrastructura și procesele de dezvoltare. Nicio metodă individuală nu garantează securitatea completă — este necesară o combinație de practici.

Primul nivel — prevenirea: validarea strictă a tuturor datelor de intrare. Fiecare câmp pe care aplicația îl primește de la utilizator, altă aplicație sau rețea trebuie verificat pentru tip, lungime și format. Bibliotecile precum OWASP ESAPI oferă validatori gata pregătiți pentru scenarii comune.

Al doilea nivel — sanitizarea și escaparea: transformarea datelor înainte de utilizarea lor în interogări SQL, șabloane HTML sau comenzi shell. Interogările parametrizate elimină complet SQL Injection, iar escaparea HTML previne XSS. Pe Android, pentru lucrul cu SQLite utilizați Room — ORM care aplică automat parametrii bind.

Al treilea nivel — minimizarea privilegiilor: aplicația trebuie să funcționeze cu cele mai mici drepturi necesare. Aplicați principiul celui mai mic privilegiu pentru baza de date, sistemul de fișiere și comunicarea interproces. iOS implementează acest principiu prin sandbox-ul aplicațiilor, iar Android — prin modelul de permisiuni și izolarea proceselor.

Al patrulea nivel — monitorizarea și reacția: înregistrarea operațiunilor suspecte, detectarea anomaliiilor și blocarea automată la atacuri repetate. Instrumente precum Firebase App Check ajută la detectarea cererilor false către backend de la clienți compromiși. Integrarea RASP (Runtime Application Self-Protection) permite blocarea injecțiilor în timp de execuție.

Conform cercetării Google Project Zero (2025), combinația acestor patru niveluri reduce riscul unui atac reușit prin Code Injection cu 94%. Dezvoltatorilor li se recomandă implementarea mecanismelor de protecție în faza de proiectare a arhitecturii, nu după descoperirea vulnerabilității.