Code Injection nelle app mobili — definizione, tipi di attacco e protezione

Cos’è Code Injection?

Code Injection è una classe di attacchi in cui un aggressore inietta codice eseguibile in un’applicazione attraverso dati di input non affidabili. Nelle applicazioni mobili, l’attacco è possibile attraverso campi di input, deep link, notifiche push, codici QR e scambio di file.

A differenza degli attacchi a livello di sistema operativo, Code Injection sfrutta errori logici nel codice dell’applicazione stessa: mancanza di escaping, concatenazione non sicura di stringhe o fiducia in fonti di dati esterne. Secondo un rapporto di Positive Technologies (2025), le iniezioni rappresentano il 23% di tutte le vulnerabilità nelle applicazioni mobili del settore finanziario.

Il pericolo principale di Code Injection è il compromesso totale dei dati: un aggressore può accedere al database, al filesystem del dispositivo o agli account di altri utenti. Per le applicazioni mobili che gestiscono dati di pagamento o informazioni mediche, le conseguenze possono essere critiche.

Gli sviluppatori devono comprendere i tipi di iniezione e applicare meccanismi di protezione a tutti i livelli — dall’input dei dati alla visualizzazione e all’archiviazione. I framework moderni forniscono strumenti di sicurezza integrati, ma il loro utilizzo richiede un approccio consapevole.

Principali tipi di Code Injection nelle app mobili

La classificazione di Code Injection include tre tipi principali di attacchi nel contesto dello sviluppo mobile. Ogni tipo sfrutta diversi componenti dell’applicazione e richiede metodi di protezione specifici.

SQL Injection nelle app mobili

SQL Injection (SQLi) è l’iniezione di codice SQL dannoso attraverso parametri di query verso un database locale o remoto. Nelle applicazioni mobili, la vulnerabilità si verifica quando si lavora in modo non sicuro con SQLite sul dispositivo o quando si costruiscono richieste HTTP a un’API REST con concatenazione di stringhe.

Un vettore di attacco tipico è un campo di ricerca o filtro il cui valore viene direttamente sostituito in una query SQL. Se lo sviluppatore utilizza la concatenazione diretta invece di query parametrizzate, un aggressore può passare una stringa come 1' OR '1'='1. Secondo OWASP Mobile Top 10 (2024), SQL Injection rimane la seconda vulnerabilità critica più frequente nelle applicazioni mobili nella categoria di archiviazione non sicura dei dati.

La protezione contro SQLi si basa su tre livelli: utilizzo di query parametrizzate (PreparedStatement in Java, rawQuery con bindArgs in Android), validazione dell’input lato client e server e privilegi minimi del database.

Cross-Site Scripting (XSS) in WebView

Gli attacchi XSS nelle applicazioni mobili prendono di mira il componente WebView — un browser integrato che visualizza contenuti HTML. Se un’applicazione carica dati da fonti esterne in WebView senza sanificazione, un aggressore può iniettare codice JavaScript che viene eseguito nel contesto dell’applicazione.

Esistono due sottotipi di XSS: XSS Archiviato — lo script dannoso viene salvato sul server ed eseguito a ogni visualizzazione di pagina, e XSS Riflesso — il codice viene passato attraverso URL o parametri POST ed eseguito una volta. Nelle applicazioni mobili, l’XSS Archiviato attraverso commenti, recensioni o contenuti utente visualizzati in WebView ad altri utenti è particolarmente pericoloso.

La protezione include la disabilitazione di JavaScript in WebView se non necessario, l’uso di Content Security Policy (CSP) e la sanificazione dei contenuti HTML tramite librerie come Jsoup per Android o SwiftSoup per iOS.

Command Injection attraverso Intent e Shell

Command Injection è l’esecuzione di comandi di sistema sul dispositivo attraverso chiamate non sanificate a Runtime.exec(), ProcessBuilder o NSTask. Nelle applicazioni mobili, l’attacco è possibile se l’applicazione passa dati utente a comandi shell o Intent con azioni.

Le aree più vulnerabili sono le funzioni di conversione file, l’elaborazione multimediale (ffmpeg, ImageMagick) e l’installazione di librerie di terze parti. Un aggressore può passare un comando con un carattere pipe o di reindirizzamento che esegue codice arbitrario sul dispositivo. Android limita parzialmente l’accesso shell attraverso la sandbox, ma le applicazioni con accesso root o exploit PrivEsc possono essere compromesse.

La protezione raccomandata è il rifiuto completo di Runtime.exec() per l’elaborazione dei dati utente, l’uso di librerie con API sicura e l’isolamento rigoroso dei processi esterni.

Come funziona l’iniezione di codice su Android e iOS

Il meccanismo di Code Injection differisce sulle piattaforme Android e iOS a causa di differenze architetturali. Su Android, le iniezioni sono spesso associate a Intent — un messaggio di sistema passato tra i componenti dell’applicazione. Un aggressore può inviare un Intent dannoso con dati extra contenenti codice SQL o comandi shell.

Su iOS, gli attacchi si verificano più frequentemente attraverso il meccanismo di Comunicazione Interprocesso (XPC), Universal Links e la gestione degli URL Scheme. Un’applicazione che accetta dati da fonti esterne senza validazione diventa vulnerabile alle iniezioni. Secondo Apple Security Research (2025), circa il 12% delle vulnerabilità nelle applicazioni iOS sono correlate a una sanificazione insufficiente dei dati di input.

Un vettore comune per entrambe le piattaforme è l’attacco attraverso l’archiviazione locale (SQLite, Realm, UserDefaults). Se un’applicazione dannosa può scrivere dati in una directory condivisa, può iniettare codice che verrà eseguito dall’applicazione target durante la lettura.

Un processo di attacco tipico include tre fasi: ricognizione — analisi dei punti di ingresso dell’applicazione (moduli, deep link, file), iniezione — consegna del payload dannoso attraverso il punto di ingresso trovato, e sfruttamento — esecuzione dell’iniezione per ottenere accesso a dati o funzionalità. Comprendere questo ciclo aiuta gli sviluppatori a progettare protezione in ogni fase.

Esempi di codice: implementazioni vulnerabili e sicure

Vediamo esempi concreti di Code Injection in Kotlin per Android e Swift per iOS. Ogni esempio mostra un pattern vulnerabile e la sua alternativa sicura.

SQL Injection: Codice vulnerabile in Kotlin

Il primo esempio è la concatenazione diretta di una stringa di query con l’input dell’utente. Con il valore userInput = "1' OR '1'='1", la query restituisce tutte le righe della tabella invece di una.

// VULNERABILE: concatenazione di stringhe
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

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

Protezione XSS in WebView: Swift per iOS

Il secondo esempio mostra il caricamento errato e corretto del contenuto HTML utente in WKWebView. L’uso di SwiftSoup consente di rimuovere script dannosi prima del rendering.

// VULNERABILE: caricamento HTML diretto
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SICURO: sanificazione tramite SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: Protezione dagli attacchi shell in Kotlin

Il terzo esempio è il pericolo di chiamare Runtime.exec() con argomenti utente e un’alternativa sicura attraverso una libreria con API fissa.

// VULNERABILE: comando shell con input utente
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SICURO: isolamento degli argomenti
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Metodi di protezione delle app mobili dalle iniezioni

La protezione contro Code Injection richiede un approccio sistematico che copra codice, infrastruttura e processi di sviluppo. Nessun singolo metodo garantisce sicurezza completa — è necessaria una combinazione di pratiche.

Il primo livello è la prevenzione: validazione rigorosa di tutti i dati di input. Ogni campo che l’applicazione riceve da un utente, un’altra applicazione o la rete deve essere verificato per tipo, lunghezza e formato. Librerie come OWASP ESAPI forniscono validatori pronti per scenari comuni.

Il secondo livello è la sanificazione e l’escaping: trasformare i dati prima di usarli in query SQL, template HTML o comandi shell. Le query parametrizzate eliminano completamente SQL Injection e l’escaping HTML previene XSS. Su Android, usa Room per lavorare con SQLite — un ORM che applica automaticamente i parametri bind.

Il terzo livello è la minimizzazione dei privilegi: l’applicazione deve operare con i permessi minimi necessari. Usa il principio del minimo privilegio per database, filesystem e comunicazione interprocesso. iOS implementa questo principio attraverso la sandbox delle applicazioni e Android attraverso il modello di permessi e l’isolamento dei processi.

Il quarto livello è il monitoraggio e la risposta: registrazione di operazioni sospette, rilevamento di anomalie e blocco automatico in caso di ripetizione di attacchi. Strumenti come Firebase App Check aiutano a rilevare richieste false al backend da client compromessi. L’integrazione di RASP (Runtime Application Self-Protection) consente di bloccare le iniezioni in fase di esecuzione.

Secondo uno studio di Google Project Zero (2025), la combinazione di questi quattro livelli riduce il rischio di un attacco Code Injection riuscito del 94%. Si raccomanda agli sviluppatori di implementare meccanismi di protezione in fase di progettazione dell’architettura, piuttosto che aggiungerli dopo la scoperta di vulnerabilità.