“Offrire un’esperienza coinvolgente agli utenti di dispositivi mobile può essere un aspetto allettante in fase di sviluppo di nuove soluzioni, ma non la priorità: è la sicurezza, piuttosto, che dovrebbe essere il punto focale nello sviluppo di qualsiasi applicazione e per ogni successivo aggiornamento. Non considerare prioritaria la sicurezza dei dati e dei dispositivi, può rendere innanzitutto i clienti vulnerabili sotto diversi punti di vista, e ciò può tradursi nella loro perdita di fiducia o scarsa fidelizzazione, oltre a comportare conseguenze economiche per gli sviluppatori, i clienti stessi, i partner e, non ultimo, gli utenti finali, a seconda del tipo di utilizzo dell’applicazione”.

Inizia così la riflessione di Darryn Campbell, Software Architect di Zebra Technologies, sulla sicurezza delle applicazioni mobile. Secondo Campbell è essenziale che gli sviluppatori tengano a mente quattro considerazioni quando verificano la capacità delle funzionalità di sicurezza delle loro applicazioni mobile. Eccole nel dettaglio.

Sicurezza prima di convenienza

Tutti i codici delle API (interfaccia di programmazione delle applicazioni) utilizzati per comunicare con servizi di terze parti inclusi all’interno dell’applicazione binaria sono per natura insicuri. Per quanto gli sviluppatori provino a rendere invisibili le key all’interno delle loro applicazioni utilizzando ProGuard o qualche sistema proprietario, ogni tentativo può essere reso vano con un minimo sforzo.

È importante dunque garantire che l’uso di qualsiasi API key sia soggetto alle restrizioni adeguate. Per esempio, se si sta creando una Web App, è utile poter gestire solo le richieste che arrivano da determinati domini o indirizzi IP; mentre per le App native si possono stabilire delle restrizioni alle key in base all’identità del gruppo o in base al nome del pacchetto di ogni applicazione e al suo certificato di firma, assicurandosi che solo le applicazioni firmate dallo sviluppatore siano in grado di usare quelle API Key. Si possono inoltre restringere le key in base all’identificativo del pacchetto o al nome del pacchetto di ciascuna domanda e al certificato di firma, assicurandosi che solo le app opportunamente firmate siano in grado di usare le rispettive API key.

Nel caso i servizi di terze parti non offrano restrizioni sufficienti sulle API key, lo sviluppatore dovrebbe considerare le chiamate proxy avvalendosi di uno tra i più importanti provider cloud sul mercato. Mai, comunque, implementare un sistema di identificazione proprio. Infatti, se può essere allettante creare un nome generico e un sistema di password per i propri utenti, concretamente è molto difficile renderlo sicuro. Se poi si ha bisogno di autenticare gli utenti della App proprietaria, è necessario optare per uno tra i gestori di Identità Digitale sicura, per esempio l’Active Directory (AD) se si tratta di un ambiente di lavoro oppure Gmail o Apple ID per gli utenti delle applicazioni mobile.

Proteggere le chiavi di firma e l’infrastruttura di sviluppo

Qualsiasi chiave o credenziale usata dalla propria App (anche quelle necessarie per pubblicarla e firmarla) non dovrebbe mai essere aggiunta ad un repository di codici sorgente pubblici. Perfino aggiungere key a un repository di archiviazione privato è rischioso, dato che si potrebbe decidere di rendere open source la propria applicazione in futuro. È inoltre possibile che il codice venga svelato o accidentalmente condiviso da uno sviluppatore.

I codici di production dovrebbero essere accessibili soltanto ai responsabili della produzione dell’App. Quando si forniscono agli sviluppatori le test key, è dunque importante assicurarsi che siano limitate alle sole funzionalità richieste. Inoltre, le key dovrebbero essere sempre tenute in file separati e cambiate periodicamente. Da ricordare infine che molte key per applicazioni di terze parti saranno connesse alle informazioni di fatturazione; potrebbero quindi esserci delle implicazioni monetarie pur senza perdita di dati.

Analisi statica per identificare potenziali problemi con le applicazioni

Idealmente, tutte le applicazioni dovrebbero essere sottoposte a Penetration Testing prima del rilascio per minimizzare problemi di codice che possono portare a violazioni della sicurezza. Attorno al Penetration testing si è sviluppata una offerta molto ampia, ma la maggior parte degli sviluppatori non ha il budget per testare ciascun rilascio.

Esistono strumenti di Open-source creati per analizzare staticamente i codici alla ricerca di qualunque problema legato alla sicurezza che potrebbe venire individuato ed essere perciò incluso nel processo di sviluppo e di rilascio dell’applicazione. Diffondere cultura intorno alle best practice di sicurezza è fondamentale perchè nessuno sviluppatore, persino i più esperti, sarà mai in grado di produrre perfettamente un codice di sicurezza ogni volta che questo sia necessario.

Prevenire la perdita di dati

Il login a un’App contiene una quantità incredibile di informazioni, alcune delle quali potrebbero aiutare un hacker a individuare i punti deboli dell’applicazione. Ovviamente, non dovrebbero mai riuscire ad accedere alle informazioni sicure; ma anche informazioni ritenute apparentemente non rilevanti potrebbero rivelare l’architettura dell’App o le librerie utilizzate, che a loro volta potrebbero contenere vulnerabilità.

L’archiviazione di file è un’altra modalità attraverso la quale una App può accidentalmente condividere dati. Se l’applicazione scrive o legge file in una cartella accessibile ad altre applicazioni, i file che vengono scritti sono di conseguenza accessibili ad altri e i file che vengono letti da quelle cartelle condivise sono soggetti a manipolazione da parte di applicazioni dannose.

È importante ricordare sempre che, come sviluppatore, si è il primo tassello nella creazione di applicazioni mobile sicure. Creare e mantenere questa filosofia di sicurezza nel corso dell’intero processo di sviluppo e rilascio è essenziale per realizzare applicazioni affidabili e sicure per i clienti.