OWASP Mobile Top 10: cos'è, elenco delle vulnerabilità e come applicarlo

Cos'è OWASP Mobile Top 10?

OWASP Mobile Top 10 è un elenco standardizzato dei rischi di sicurezza più critici specifici per le applicazioni mobili. A differenza del generale OWASP Top 10 per le applicazioni web, la versione mobile tiene conto delle specificità delle piattaforme: archiviazione locale sul dispositivo, interazione con i sensori, modalità offline e peculiarità degli store di applicazioni. Il documento è pubblicato dal 2010 e viene rivisto ogni 2–4 anni: la versione attuale per il 2024 include categorie come M1 — Improper Credential Usage e M8 — Security Misconfiguration. Il progetto è supportato da una community di oltre 500 volontari in tutto il mondo.

Storia e scopo

Originariamente, OWASP Top 10 copriva solo le applicazioni web, ma la crescita dello sviluppo mobile negli anni 2010 ha richiesto un documento separato. La prima versione di Mobile Top 10 è stata rilasciata nel 2011 e conteneva solo 7 elementi. Entro il 2024, l'elenco si è ampliato a 10 categorie, ciascuna delle quali include diversi scenari di attacco specifici. Lo scopo principale del documento è fornire a sviluppatori e team di sicurezza un linguaggio comune per discutere i rischi e prioritizzare le correzioni. Gli aggiornamenti regolari dell'elenco riflettono i cambiamenti nel panorama delle minacce: l'emergere di nuove API, l'evoluzione dei sistemi operativi (Android, iOS) e le nuove tecniche di attacco descritte nei rapporti di Positive Technologies e altri centri di ricerca.

Come si forma l'elenco OWASP Mobile Top 10

La metodologia per compilare Mobile Top 10 si basa sui dati di progetti reali: vengono analizzati i risultati di penetration test di applicazioni mobili, rapporti di incidenti e ricerche sulle vulnerabilità. Ogni categoria viene valutata in base a due parametri: tasso di incidenza (Incidence Rate) e impatto tecnico (Technical Impact). La combinazione di queste metriche forma la classifica finale. A differenza degli elenchi soggettivi, OWASP utilizza dati aperti: qualsiasi membro della community può inviare una richiesta per includere una nuova categoria tramite il repository GitHub del progetto. Per la versione attuale del 2024, sono stati elaborati oltre 300.000 test di sicurezza provenienti da 25 paesi, rendendo le statistiche rappresentative dell'ecosistema globale dello sviluppo mobile. Inoltre, OWASP pubblica MASVS (Mobile Application Security Verification Standard) — un insieme di requisiti di sicurezza dettagliati che include oltre 80 controlli specifici distribuiti in 8 categorie. MASVS viene utilizzato come base per la certificazione delle applicazioni e come lista di controllo per i penetration test: ogni requisito ha un riferimento a una categoria di Mobile Top 10, garantendo la tracciabilità tra lo standard e l'elenco dei rischi.

Panoramica delle principali vulnerabilità della top 10

Esaminiamo le tre categorie più critiche di OWASP Mobile Top 10 2024, che coprono oltre il 70% di tutti gli incidenti di sicurezza nei progetti mobili. Ogni categoria include scenari di sfruttamento specifici e raccomandazioni di protezione.

Uso improprio della piattaforma

Questa categoria (M1) copre le situazioni in cui gli sviluppatori utilizzano API e meccanismi di piattaforma in modo improprio. Esempi tipici: Intent Injection su Android, gestori di Deep Link aperti su iOS, gestione errata di Keychain e SharedPreferences. Un aggressore può inviare un Intent appositamente creato e ottenere l'accesso ai dati di un'altra applicazione o componente. Secondo il rapporto NowSecure (2023), il 22% delle applicazioni Android testate conteneva vulnerabilità di tipo Intent Redirection. La protezione include: validazione rigorosa dei dati di input, verifica dell'origine dell'Intent e utilizzo delle autorizzazioni per i componenti esportati.

Archiviazione non sicura dei dati

Archiviazione non sicura dei dati (M2) è il problema più comune nelle applicazioni mobili. Si verifica quando i dati sensibili (token di accesso, password, dati personali) vengono memorizzati in chiaro o con protezione insufficiente. Fonti tipiche di vulnerabilità: database SQLite senza crittografia, SharedPreferences senza EncryptedSharedPreferences, registrazione dei dati in modalità debug. Secondo OWASP Foundation (2024), oltre il 60% delle applicazioni gratuite su Google Play memorizza almeno un tipo di dati sensibili in forma non crittografata. La soluzione è utilizzare Android EncryptedSharedPreferences, iOS Keychain e crittografare i dati prima di scriverli nell'archivio locale.

Comunicazione non sicura

La categoria M3 — Comunicazione non sicura — include vulnerabilità nei canali di trasmissione dati tra l'app e il server. Mancanza di HTTPS, validazione errata dei certificati SSL, uso di protocolli TLS 1.0/1.1 obsoleti — tutti questi problemi consentono a un aggressore di intercettare il traffico attraverso attacchi Man-in-the-Middle. La situazione è particolarmente pericolosa quando l'applicazione gestisce dati sensibili (transazioni bancarie, informazioni mediche) attraverso un canale non protetto. Nel 2023, i ricercatori di NCC Group hanno scoperto che il 12% delle applicazioni finanziarie più popolari utilizza una configurazione TLS errata. Raccomandazione: uso obbligatorio di HTTPS con Certificate Pinning e rifiuto di HTTP nelle build di produzione.

Come testare le applicazioni secondo OWASP Mobile Top 10

Il test di sicurezza di un'applicazione mobile secondo la metodologia OWASP include diverse fasi: analisi statica del codice (SAST), analisi dinamica (DAST) e test manuali (penetration test). Ogni fase mira a identificare specifiche categorie di vulnerabilità da Mobile Top 10.

Strumenti di test

Per l'analisi automatizzata, OWASP raccomanda l'uso di MobSF (Mobile Security Framework) — uno strumento open source. MobSF esegue l'analisi statica del codice sorgente e dei file binari, verifica la configurazione del manifest, analizza le autorizzazioni e identifica le vulnerabilità da Mobile Top 10. Per l'analisi dinamica vengono utilizzati Burp Suite (proxy per l'intercettazione del traffico) e Frida (strumento di analisi runtime). La combinazione di questi strumenti copre oltre l'80% delle categorie dell'elenco. Test regolari in una pipeline CI/CD con MobSF consentono di identificare le vulnerabilità nelle prime fasi di sviluppo e riducono il costo della loro correzione del 60–70%. L'integrazione degli strumenti SAST e DAST nella pipeline dovrebbe essere automatizzata tramite plugin Gradle/Maven o passaggi Fastlane nelle build iOS.

Interpretazione del rapporto MobSF

Dopo aver eseguito MobSF, lo sviluppatore riceve un rapporto con indicatori di colore: rosso — vulnerabilità critica, arancione — rischio medio, giallo — rischio basso. Ogni avviso contiene un riferimento alla corrispondente categoria OWASP Mobile Top 10, una descrizione del problema e una raccomandazione di correzione. È importante non solo eliminare gli avvisi rossi ma anche analizzare quelli arancioni: molti di essi (ad esempio, Activity esportate senza protezione) possono combinarsi per dare a un aggressore un vettore di attacco. Si raccomanda di raggiungere zero avvisi rossi e non più di 2–3 arancioni prima di ogni rilascio. Il rapporto MobSF include anche un'analisi delle autorizzazioni dell'applicazione: qualsiasi autorizzazione eccessiva (ad esempio, accesso alla fotocamera in una calcolatrice) viene segnalata come violazione del principio del minimo privilegio e deve essere rimossa dal manifest. Per le applicazioni iOS, MobSF esegue un'analisi simile dei file .ipa, inclusa la verifica di Info.plist per le eccezioni ATS e l'analisi dei binari Mach-O per API non sicure come NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}