Mobile application security: l’app gira in casa del nemico

Mobile application security è la sicurezza di un tipo di software che ha una caratteristica unica e spesso rimossa: gira su un dispositivo che chi lo sviluppa non controlla, e che in molti casi è proprio nelle mani di chi vorrebbe attaccarlo. Il codice di un server vive in un data center sorvegliato; un’app mobile vive su un telefono che può essere modificato per ottenere privilegi di amministratore, ispezionato mentre è in esecuzione, decompilato per leggerne l’interno, e il cui archivio locale può essere estratto. È una differenza che cambia tutto, perché ribalta l’assunzione di base su cui poggia gran parte della sicurezza applicativa.

Il peccato originale, in questo campo, è trattare l’app mobile come un client fidato. È l’errore di chi ragiona come per il web, dove il browser dialoga con un server che resta il custode della logica e dei segreti. Sul mobile non funziona così: tutto ciò che finisce dentro l’app, una chiave, una credenziale, una porzione di logica sensibile, è alla portata di chi possiede il dispositivo. La mobile application security parte da qui, dall’accettare che l’ambiente in cui l’app gira è ostile e che il client, a differenza del server, può essere in mano al nemico.

Il client è in mano al nemico

Conviene rendere concreta questa ostilità, perché è ciò che distingue il mobile dal resto. Un dispositivo con privilegi di amministratore ottenuti tramite rooting o jailbreak permette al suo possessore di aggirare le protezioni del sistema operativo e di leggere ciò che le app credono protetto. Strumenti di instrumentation consentono di osservare e manipolare un’app mentre gira, intercettandone le funzioni e i valori in memoria. La decompilazione apre il codice all’analisi, rivelando segreti incorporati e logiche che si pensavano nascoste. E il traffico verso i server può essere intercettato da chi controlla la rete o il dispositivo.

La conseguenza pratica è una serie di errori ricorrenti che derivano tutti dalla stessa illusione di fiducia. Conservare dati sensibili nell’archivio locale come se fosse al sicuro è il problema più comune e più grave del mobile, perché quei dati si possono estrarre. Incastonare chiavi crittografiche o segreti nel binario dell’app, nella convinzione che nessuno li troverà, è un altro classico, smentito dalla prima decompilazione. Affidarsi alla rete senza verificare l’identità del server espone all’intercettazione. Ognuno di questi errori nasce dal dare per scontato un controllo sull’ambiente che, sul mobile, semplicemente non si ha.

OWASP MASVS: lo standard che assume il peggio

A dare ordine a questo terreno c’è uno standard diventato il riferimento di settore, l’OWASP Mobile Application Security Verification Standard, noto come MASVS, affiancato da una guida ai test, il MASTG, che spiega come verificarlo nella pratica. Il valore del MASVS è che non finge che il dispositivo sia fidato: organizza la sicurezza dell’app in gruppi di controlli, ciascuno dei quali affronta un modo in cui l’assunzione dell’ambiente ostile si traduce in rischio concreto.

Nella versione 2.1.0, pubblicata nel gennaio 2024, i gruppi sono otto. Riguardano la conservazione sicura dei dati sul dispositivo, l’uso corretto della crittografia, l’autenticazione e l’autorizzazione, la sicurezza delle comunicazioni di rete, l’interazione sicura con la piattaforma mobile, la qualità del codice, la resistenza alla manomissione e all’analisi inversa, e infine la privacy, gruppo aggiunto proprio nel 2024 a riconoscere quanto privacy e sicurezza siano ormai inseparabili. È un quadro che copre l’app dal dato che custodisce fino al modo in cui parla con il mondo, e che si appoggia a pratiche di secure coding e ai meccanismi di autenticazione, inclusi quelli biometrici, che il sistema operativo mette a disposizione.

Mobile application security e il caso speciale della resilienza

Tra gli otto gruppi ce n’è uno che merita un discorso a parte, perché è il più frainteso: la resistenza alla manomissione e all’analisi inversa, la resilienza nel linguaggio del MASVS. Sono le protezioni che rendono più difficile decompilare un’app, individuarne i punti deboli o modificarla: offuscamento del codice, rilevamento del rooting, difese contro l’instrumentation. Per certe categorie di applicazioni, quelle bancarie, dei pagamenti, della gestione di contenuti protetti, alzare questa barriera ha senso, perché aumenta il costo e il tempo necessari a un attaccante mirato.

Qui però si annida un equivoco da evitare. La resilienza è una difesa in profondità, non un sostituto delle altre. Offuscare il codice e ostacolare l’analisi rallenta chi attacca, non lo ferma: un avversario determinato e con tempo a disposizione supera comunque queste barriere. Confondere il rendere un’app difficile da decifrare con il renderla sicura è uno degli errori più costosi, perché porta a investire nella corazza esterna mentre dentro restano segreti nel binario e dati in chiaro nell’archivio locale. Lo stesso standard colloca la resilienza come livello aggiuntivo per i casi ad alto rischio, non come la base su cui costruire. La sicurezza vera di un’app sta prima nei controlli fondamentali, e solo dopo, dove serve, nella resistenza all’analisi.

Verificare, non sperare

Il merito di avere uno standard è proprio questo: trasformare la sicurezza da auspicio a verifica. Accanto al MASVS, il progetto OWASP MAS fornisce la guida ai test e una lista di controllo che permettono di misurare un’app rispetto ai requisiti, in modo ripetibile e documentabile. Dalla versione 2.0 lo standard ha anche abbandonato i vecchi livelli di verifica fissi, sostituiti da profili di test calibrati sulla criticità dell’applicazione, così che il rigore del controllo si adatti al rischio reale e non sia uguale per un gioco e per un’app bancaria. È la differenza tra credere che un’app sia sicura e poterlo dimostrare, controllo per controllo, integrando queste verifiche nel ciclo di sviluppo come si fa con il resto della pipeline DevSecOps.

Perché conta adesso

Il mobile non è più un canale accessorio, è il luogo dove avvengono le operazioni più sensibili: pagamenti, identità digitale, accesso ai servizi sanitari e bancari, autenticazione verso decine di altri sistemi. L’app è diventata la porta d’ingresso principale, e una porta che si trova fisicamente nelle tasche di chiunque, incluso chi ha interesse a forzarla. A questo si aggiunge la convergenza tra sicurezza e privacy, riconosciuta dallo stesso MASVS con il gruppo dedicato, e una pressione normativa crescente sulla protezione dei dati trattati dalle applicazioni.

In questo quadro, la mobile application security non è una specializzazione di nicchia per chi scrive app, ma una parte centrale della superficie d’attacco di qualunque organizzazione che offra i propri servizi tramite uno smartphone. La sua lezione di fondo è scomoda e preziosa: a differenza di quasi ogni altro software, un’app mobile deve restare sicura anche quando l’ambiente attorno è completamente compromesso. Chi progetta pensando che il telefono sia un posto sicuro costruisce l’app che prima o poi lascerà uscire ciò che doveva custodire. Chi parte dall’assunzione opposta, e usa uno standard come il MASVS per metterla alla prova, costruisce un’app che regge anche in casa del nemico.

https://www.ictsecuritymagazine.com/cyber-security/mobile-application-security/