Analizzando diverse applicazioni per Android e Windows Phone 7 è interessante notare come molte applicazioni, nella tecnica di sviluppo, utilizzino pratiche degli anni ’90.  Lo sviluppo di applicazioni è facile, divertente e in alcuni casi è in grado di fornire un ROI (ritorno degli investimenti) abbastanza veloce. Tutto questo ha scatenato lo sviluppo di migliaia di applicazioni per le principali piattaforme, nonostante questo vorremmo che non si ignorassero le conoscenze di sicurezza acquisite fin ora. OWASP (Open Web Application Security Project), un’associazione no profit che si concentra sul miglioramento della sicurezza del software delle applicazioni, ha steso una lista delle 10 pincipali vulnerabilità che colpisce le moderne app.

Non è difficle trovare dei bug nelle più popolari app (giochi, banche, finanza, sicurezza, social) in cui è rischiesta la massima sicurezza. Ecco un piccolo schema che riassume la quantità di bug presenti e anche se, non sono tutti presenti, rende l’idea della pericolosità di questi software.

La cosa più sconvolgente è che questi bug sono molto conosciuti e la soluzione per scrivere un codice più sicuro esiste da anni ed è ormai alla conoscenza di tutti i programmatori. Non vi è alcuna scusa per queste mancanze. Sicuramente molti sviluppatori non sono anche venditori dei propri prodotti e quindi la colpa va in gra parte attribuita alle software house. Analizzeremo nel dettaglio i principali bug e speriamo che questi non siano più presenti nelle applicazioni mobili.

 

 

Testo segreto, in chiaro

Questo è un classico bug che si verifica quando lo sviluppatore non si preoccupa di proteggere alcune informazioni sensibili mediante crittografia o altri mezzi di sicurezza perché considera l’applicazione al sicuro da attacchi. Per esempio: l’applicazione non prevede la crittografia delle password prima che vengano memorizzate in un file .xml o in un database. Sia Android che Win7 prevedono una facile memorizzazione dei dati in modo da recuperarli senza problemi, tuttavia la sicurezza deve essere un problema dello sviluppatore. Di solito questo bug su Android può essere trovato esaminando la directory dell’applicazione, come illustrato nel codice dell’immagine seguente.

 

Canali di comunicazione non sicuri

Molte applicazioni mobili comunicano con i sistema su Internet, utilizzando i servizi web per lo scambio di informazioni, aggiornamenti e così via. Il problema si pone quando le informazioni in transito quando la crittografia non è utilizzata per proteggere il canale di comunicazione. Un utente malintenzionato può spiare i dati in transito tra lo smartphone e il server soprattutto se si tiene in considerazione il fatto che molti utilizzano il proprio smarthfone con Wi-Fi.  Esempio: quando un app crea una query utilizzando un URL HTTP GET metodo senza crittografia e include sensibili informazioni.

Gli sviluppatori dimenticato che le richieste GET sono spesso memorizzate nei log (proxy, server web, ecc.).

 

Codice di debug abilitato

Nello sviluppo di un software è pratica comune abilitare il codice di debug. Il problema si pone quando lo sviluppatore si dimentica di disabilitare questa funzione e quindi consente a qualsiasi malintenzionato di visualizzare degli output utili a sfruttare i problemi dell’applicazione. Con Android è possibile eseguire il backup utilizzando Dalvik Debug Monitor Server (DDMS), ma fornisce anche alcune classi come util, Log e debug che può essere utilizzato all’interno di un app. Su Windows Phone 7 siamo in grado di utilizzare Visual Studio 2010 per il debug.

L’immagine mostra il codice di una app Android e si nota come la classe di debug sia ancora abilitata.

 

 SQL dinamico

Tutti hanno sentito parlare di SQL injection, ma si possono ancora trovare un sacco di applicazioni (mobile e non) che soffrono di questo tipo di bug grazie all’utilizzo di SQL dinamico e la mancanza di convalida dei dati. Presumo che quando si tratta di mobili applicazioni, gli sviluppatori non sono così interessati alle SQL injection e spesso utilizzano un codice molto semplice.  Android utilizza SQLite per memorizzare i dati mentre Windows Phone 7 non ha un database di supporto e quindi abbiamo bisogno di usare servizi esterni come SQL Azure. Smartphone e Tablet stanno entrando a far parte della vita di tutti i giorni e sono sempre più spesso di supporto alle aziende implementando applicazioni LOB (Line of Business). Lo sviluppatore deve quindi stare molto attento ad evitare questo tipo di bug. Si potrebbe sostenere che sono difficili da sfruttare ma come ci insegna la storia dell’informatica, sono successe cose perggiori in passato a causa di queste trascuratezze. Nell’immagine sottostatne c’è un esempio di un app che memorizza le informazioni nel database (SQLite) utilizzando SQL dinamico e nessun dato prevede la verifica, che quindi consente ad un utente malintenzionato il controllo della paramString valore per eseguire SQL injection.

 

 Cross-Site Scripting (XSS)

XSS è un altro vecchio classico quando si tratta di sicurezza delle applicazioni. XSS e SQL Injection sono il tipo più comune di bug su Applicazioni Web. C’è abbondanza di soluzioni per l’ XSS ma appare ancora un po’ ovunque. SQL Injection e XSS sono difficili da sfruttare ma non dovrebbero essere sottovalutati nel settore mobile. Dato che questa è una notizia vecchia e non voglio spendere troppo tempo su questo argomento, basta fare attenzione quando si usa la classe WebView su Android e le classi WebClient e HttpWebRequest su Windows Phone 7.

 

 Raccolta di informazioni

Il collegamento delle applicazioni ai server per la ricerca di aggiornamenti e altro, non dovrebbe essere di per se un problema ma in alcuni casi queste estraggono troppe informazioni (apparentemente inutili) relative all’utente che le utilizza. Dall’analisi di una qualsiasi applicazione è infatti possibile notare come vengono raccolti questi dati e generalmente l’utente non ha nessun controllo su questo. Anche Google e Apple sono stati recentemente accusati di raccogliere informazioni sulla posizione dei loro utenti. Ma se analizziamo diverse applicazioni vediamo che questa è un usanza abbastanza diffusa che accomuna piccoli e grandi produttori di software. Onestamente non si sa qual’è il male minore, se questi dati vengano raccolte da una grande o piccola azienda che produce app. L’immagine sottostante è un ottimo esempio di una applicazione per cellulare che raccoglie troppe informazioni (ad esempio modello del cellulare, sistema operativo, nome ecc..)

Essendo questa un’applicazione per finanza, si potrebbe discutere sulla necessità di acuisire queste informazioni. Certo, ci sono diversi OS e diverse dimensioni dello schemo ma non sono convinto che questo basti per giustificare tutto questo invio di dati.

Social apps

Oggi per essere visibile nel mondo digitale, sembra che sia indispensabile essere su Facebook o Twitter. Ovviamente tutto questo non è un problema ma diventa pericoloso quando la connessione con questi account viene inserita in applicazioni che invece hanno necessiatà di essere sicuro quasi al 100%. Durante alcune ricerche di applicazioni bancarie che hanno Facebook integrato (non si capisce perchè abbiate il bisogno degli amici durante il pagamento delle bollette) iniziano a sorgere dei problemi. Come abbiamo spiegato in precedenza, le applicazioni dei social network non sono protette a sufficienza (testo segreto, in chiaro). Inoltre perchè la banca deve accedere alla lista conttatti dei nostri amici? Esse collegati con il mondo esterno attraverso i social network è una buona cosa ma c’è un limite e gli sviluppatori dovrebbero tenerne conto. Se un’applicazione deve interagire con Facebook, Twitter o altro è necessario che sia programmata in modo sicuro.

 

Convalida dei dati

E’ un fatto che molti bug sono legati alla convalida dei datie purtroppo le applicazioni per cellulari non ne fanno eccezione. Questi sono molti e facili da trovare dato che gli sviluppatori non tengono conto del controllo di lunghezza, tipo e genere del dato. Nell’immagine sottostante vi è un chiaro esempio in cui l’applicazione non esegue nessuna convalida dei dati sull’input fornito dall’utente.

Lo sviluppatore presuppone che il contesto in cui viene utilizzato il suo codice sia buono e che quindi non ci siano malintenzionati pronti a sfruttare il bug. Esaminando il codice si può anche notare che le informazioni vengono salvate sul registro e questo è un problema perchè su potrebbe tranquillamente inserire della spazzatura saturando il registro e quindi provocando il blocco del dispositivo vista la poca memoria a disposizione (DOS). Oppure si potrebbe inserire del codice dannoso e attendere il momento migliore per farlo partire dal registro di sistema del cellulare. Questo tipo di bug è ancora molto diffuso e non ci sono più scuse per non tenerne conto vista la disponibilità di strumenti per il controllo.

 

Deboli algoritmi di crittografia

Uno sviluppatore non dovrebbe mai cercare di sviluppare il suo algoritmo di crittografia, in quanto questo è solo una ricetta per il fallimento. Invece, dovrebbero sfuttare le librerie che utilizzano forti algoritmi come AES e così via. Entrambe le piattaforme offrono forti algoritmi crittografici tra cui scegliere, ma la questione si pone quando lo sviluppatore li implementa inefficacemente o sceglie la soluzione non corretta, come utilizzando un algoritmo di hash che non viene utilizzato per la crittografia di informazioni sensibili.

 

Conclusione

A questo punto dovrebbe essere chiaro che , allo stato, la sicurezza delle applicazioni mobili deve essere migliorata e che gli sviluppatori devo comprendere i rischi e seguire delle sicure pratiche di sviluppo. Allo stesso modo i creatori delle piattaforme devono fornire strumenti per la sicurezza e delle migliori guide in modo che gli sviluppatori indipendenti le possano utilizzare per creare app sicure. Speriamo che la ricerca possa umentare la consapevolezza di una maggiore sicurezza delle applicazioni mobili. La maggior parte degli esperti di sicurezza si concentrano nella ricerca di falle sulla stessa piattaforma ma, che senso ha avere una piattaforma sicura quando ci sono migliaia di applicazioni insicure? Il punto cruciale è che le applicazioni diventino sicure così come le piattaforme (iPad, tablet Android, e possibilmente tablet Windows 8). Risulta molto importante che gli utenti acquisiscano consapevolezza sollevino questi problemi. L’indistria della sicurezza deve continuare a sensibilizzare gli utenti sui pericoli che corrono e sulle pessime applicazioni che spesso utilizzano. Ecco alcuni consigli per affrontare la sicurezza di applicazioni mobili:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *