Comprendere i 10 principali rischi di OWASP Mobile con casi reali

Portare un record del settore nello sviluppo di applicazioni a prova di hacking al 100% comporta una responsabilità e una garanzia di base che nessuna delle soluzioni digitali sviluppate sotto il nostro nome sarebbe soggetta a violazioni della sicurezza.

Per raggiungere questo obiettivo, il team di garanzia della qualità di Appinventiv ha familiarità con tutti i possibili rischi per la sicurezza che un'app può affrontare. Conoscere i rischi rende facile ignorare le insidie ​​e scrivere app sicure.

Aiutarci a essere in cima al gioco quando si tratta di garantire la sicurezza è avere una conoscenza completa delle pratiche di codifica sicura OWASP (Open Web Application Security Project). È una comunità online di specialisti della sicurezza che ha sviluppato documentazione gratuita, materiali didattici e strumenti per la creazione di applicazioni Web e mobili sicure.

Insieme ad altre cose, hanno anche compilato un elenco delle 10 principali minacce alla sicurezza di OWASP Mobile nelle applicazioni mobili.

Sebbene il documento sulle pratiche di sicurezza OWASP sia abbastanza chiaro, a volte può essere difficile per le aziende collegarlo da casi reali.

In questo articolo, ti forniremo una panoramica di base dei 10 principali rischi per la sicurezza mobile e forniremo esempi delle vulnerabilità rivelate nel mondo reale per ciascuno di essi. Ti darà un'idea di ciò per cui ci prepariamo in Appinventiv quando lavoriamo alla tua applicazione.

Prima di esaminare i rischi, esaminiamo le statistiche.

NowSecure ha esaminato le app su Google Play Store e App Store ha identificato che oltre l'85% delle app viola uno dei rischi.

Di queste applicazioni, il 50% disponeva di un'archiviazione dei dati non sicura e da qualche parte lo stesso numero di app funzionava con un rischio di comunicazione non sicuro . Ecco un grafico che mostra la percentuale di accadimento dei 10 principali rischi di OWASP Mobile

Elenco delle 10 minacce più comuni alle applicazioni mobili e delle migliori pratiche per evitarle

M1: Utilizzo improprio della piattaforma

La categoria dei test di sicurezza OWASP consiste nell'uso improprio della funzionalità di un dispositivo o nell'istanza di errore durante l'utilizzo dei controlli di sicurezza della piattaforma. Può includere autorizzazioni della piattaforma, intenti Android, uso improprio di TouchID, portachiavi, ecc.

Caso nel mondo reale:

Tre app iOS : "App Fitness Balance", "Cardiofrequenzimetro" e "App Calories Tracker" sono venute alla luce per bypassare il Touch ID di Apple. Chiedevano agli utenti di utilizzare la propria impronta digitale per ottenere informazioni sull'attività fisica, mentre la utilizzavano per addebitare denaro dall'App Store.

Best Practice da evitare:

• Lo sviluppatore non deve consentire la crittografia del portachiavi tramite il percorso del server e mantenere le chiavi in ​​un solo dispositivo, in modo che sia impossibile essere sfruttato su altri server o dispositivi.
• Lo sviluppatore deve proteggere l'app tramite Portachiavi per archiviare il segreto dell'app con un elenco di controllo di accesso dedicato.
• Lo sviluppatore deve ottenere l'autorizzazione per limitare le app che possono comunicare con la propria applicazione.
• Lo sviluppatore deve controllare la prima della lista OWASP Mobile Top 10 definendo gli intenti espliciti e bloccando così tutti gli altri componenti per accedere alle informazioni presenti nell'intento.

M2: archiviazione dati non sicura

OWASP lo considera una minaccia quando qualcuno ottiene l'accesso a un dispositivo mobile smarrito/rubato o quando un malware o un'altra app riconfezionata inizia ad agire per conto dell'avversario ed esegue un'azione sul dispositivo mobile.

Una vulnerabilità di archiviazione dei dati non sicura di solito porta a questi rischi:

• Frode
• Furto d'identità
• Perdita materiale.
• Danno alla reputazione
• Violazione delle norme esterne (PCI)

Caso nel mondo reale :

App di appuntamenti come Tinder, OKCupid e Bumble sono state più volte esaminate per le loro pratiche di archiviazione dei dati non sicure. Le interruzioni di sicurezza presenti su queste app variano in base alla fattibilità, alla gravità e alla fattibilità, possono esporre il nome degli utenti, i dettagli di accesso, la cronologia dei messaggi e persino la posizione, oltre ad altre attività dell'account personale.

Migliori pratiche da evitare:

• Per iOS, le pratiche di sicurezza OWASP consigliano di utilizzare app vulnerabili appositamente realizzate come iGoat per modellare le minacce del proprio framework di sviluppo e delle app. Ciò aiuterà gli sviluppatori di app iOS a capire come le API gestiscono i processi delle app e le risorse informative.
• Gli sviluppatori di app Android possono utilizzare la shell Android Debug Bridge per controllare i permessi dei file dell'app di destinazione e DBMS per controllare la crittografia del database. Dovrebbero anche utilizzare lo strumento di analisi della memoria e il monitor del dispositivo Android per garantire che la memoria del dispositivo non contenga dati non desiderati.

M3: Comunicazione insicura

Quando si progetta un'app mobile, i dati vengono scambiati nel modello client-server. Quindi, quando i dati vengono trasmessi, dovrebbero prima attraversare la rete dell'operatore del dispositivo e Internet. Gli agenti di minaccia potrebbero sfruttare le vulnerabilità e intercettare dati sensibili mentre viaggiano attraverso il cavo. Ecco i diversi agenti di minaccia che esistono:

• Avversario che condivide la tua rete locale: un Wi-Fi compromesso
• Dispositivi di rete o carrier: ripetitori cellulari, proxy, router, ecc.
• Malware sul dispositivo mobile.

L'intercettazione di dati sensibili attraverso il canale di comunicazione finirebbe in una violazione della privacy, che può portare a:

• Furto d'identità
• Frode
• Danno reputazionale.

Caso nel mondo reale:

La società di sicurezza Rapid7 ha rivelato diverse vulnerabilità legate agli smartwatch per bambini. Quegli orologi sono stati commercializzati come quelli utilizzati dai genitori per rintracciare i propri figli e inviare loro messaggi o effettuare chiamate sul proprio smartwatch.

Gli orologi avrebbero dovuto essere contattati da numeri di contatto approvati tramite la modalità di una lista bianca, ma la società ha scoperto che i filtri non funzionavano nemmeno. Gli orologi accettavano anche comandi di configurazione tramite messaggi di testo. Significava che un hacker poteva modificare le impostazioni dell'orologio e mettere a rischio i bambini.

"Puoi identificare dove si trova il telefono o il bambino, puoi accedere all'audio o fare telefonate ai bambini", ha affermato Deral Heiland, responsabile della ricerca IoT di Rapid7.

Migliori pratiche da evitare:

• Gli sviluppatori non dovrebbero solo cercare perdite nel traffico comunicato tra app e server, ma anche nel dispositivo che contiene l'app e un altro dispositivo o rete locale.

• L'applicazione di TLS/SSL per il trasporto dei canali è anche una delle best practice per la sicurezza delle app mobili da considerare quando si tratta di trasmettere informazioni riservate e altri dati sensibili.

• Utilizza i certificati forniti da verifiche della catena SSL affidabili.
• Non inviare dati sensibili su canali alternativi come MMS, SMS o notifiche push.
• Applicare un livello di crittografia separato ai dati sensibili prima di inviarli al canale SSL.

M4: Autenticazione non sicura

Gli agenti di minaccia che sfruttano le vulnerabilità di autenticazione lo fanno tramite attacchi automatici che utilizzano strumenti personalizzati o disponibili.

L'impatto sul business di M4 può essere:

• Furto di informazioni
• Danno reputazionale
• Accesso non autorizzato ai dati.

Caso nel mondo reale :

Nel 2019, una banca statunitense è stata hackerata da un cyber-attaccante che ha approfittato del difetto del sito web della banca e ha aggirato l'autenticazione a due fattori implementata per la protezione dei conti.

L'attaccante ha effettuato l'accesso al sistema tramite le credenziali della vittima rubata e una volta raggiunta la pagina in cui doveva essere inserito il PIN o la risposta di sicurezza, l'attaccante ha utilizzato una stringa manipolata nell'URL Web, che aveva impostato il computer come riconosciuto. Ciò gli ha permesso di attraversare il palco e avviare i bonifici.

Migliori pratiche da evitare:

• Il team di sicurezza dell'app deve studiare l'autenticazione dell'app e testarla tramite attacchi binari in modalità offline per determinare se può essere sfruttata.
• I protocolli di sicurezza dei test delle applicazioni Web OWASP devono corrispondere a quelli delle app mobili.
• Utilizza il più possibile i metodi di autenticazione online, proprio come nel caso del browser web.
• Non abilitare il caricamento dei dati dell'app finché il server non ha autenticato le sessioni utente.
• I luoghi in cui i dati locali vengono eventualmente forniti, assicurano che siano crittografati tramite chiave crittografata derivata dalle credenziali di accesso degli utenti.
• Anche la richiesta di autenticazione persistente deve essere archiviata sul server.
• Il team di sicurezza dovrebbe prestare attenzione con i token di autorizzazione incentrati sul dispositivo nell'app, poiché se il dispositivo viene rubato, l'app può diventare vulnerabile.
• Poiché l'accesso fisico non autorizzato ai dispositivi è comune, il team di sicurezza deve imporre l'autenticazione delle credenziali utente regolare dal server.

M5: Rischi crittografici insufficienti

Gli agenti di minaccia in questo caso sono quelli che hanno l'accesso fisico ai dati che sono stati crittografati in modo errato. O dove un malware agisce per conto di un avversario.

La crittografia rotta generalmente risulta in questi casi:

• Furto di informazioni
• Furto di proprietà intellettuale
• Furto di codice
• Violazioni della privacy
• Danno reputazionale.

Caso nel mondo reale :

A volte fa un avviso del team di risposta alle emergenze informatiche di DHS Industrial Control Systems e l'avviso Philips avvisavano gli utenti di una possibile vulnerabilità nell'app Philips HealthSuite Health per Android .

Il problema, che è stato ricondotto a un livello di crittografia inadeguato, ha aperto l'app agli hacker che potevano accedere all'attività della frequenza cardiaca, alla pressione sanguigna, allo stato del sonno, all'analisi del peso e della composizione corporea degli utenti, ecc.

Migliori pratiche da evitare:

• Per risolvere questo uno dei più comuni rischi OWASP Top 10 Mobile , gli sviluppatori devono scegliere moderni algoritmi di crittografia per crittografare le loro app. La scelta dell'algoritmo si occupa della vulnerabilità in larga misura.
• Se lo sviluppatore non è un esperto di sicurezza, deve astenersi dal creare codici di crittografia propri.

M6: Rischi di autorizzazione non sicuri

In questo caso, gli agenti delle minacce sono in grado di accedere all'applicazione di qualcun altro in genere tramite attacchi automatici che utilizzano strumenti personalizzati o disponibili.

Può portare ai seguenti problemi:

• Furto di informazioni
• Danno reputazionale
• Frode

Caso nel mondo reale :

Gli specialisti della sicurezza delle informazioni di Pen Test Partners hanno violato Pandora , un sistema di allarme per auto intelligente. In teoria, l'applicazione viene utilizzata per rintracciare un'auto, spegnere il motore in caso di furto e chiuderlo fino all'arrivo della polizia.

Dall'altro lato della medaglia, un hacker può dirottare l'account e ottenere l'accesso a tutti i dati e alle funzionalità di allarme intelligente. Inoltre, potrebbero:

• Tieni traccia dei movimenti del veicolo
• Abilita e disabilita il sistema di allarme
• Blocca e sblocca le portiere dell'auto
• Spegni il motore
• Nel caso di Pandora, gli hacker hanno avuto accesso a tutto ciò di cui si parlava all'interno dell'auto attraverso il microfono del sistema antifurto.

Migliori pratiche da evitare:

• Il team QA deve testare regolarmente i privilegi dell'utente eseguendo token di sessione con privilegi bassi per i comandi sensibili.
• Lo sviluppatore deve notare che gli schemi di autorizzazione dell'utente non funzionano in modalità offline.
• Il modo migliore per prevenire questo rischio consiste nell'eseguire controlli di autorizzazione per autorizzazioni e ruoli di un utente autenticato sul server, anziché sul dispositivo mobile.

M7: Rischi di scarsa qualità del codice

In questi casi, gli input non attendibili vengono passati dalle entità alle chiamate di metodo effettuate nel codice mobile. Un effetto di ciò può essere causato da problemi tecnici che possono portare a un degrado delle prestazioni, un utilizzo intenso della memoria e un'architettura front-end non funzionante.

Caso nel mondo reale :

WhatsApp l'anno scorso ha corretto una vulnerabilità di cui gli hacker stavano approfittando per l'installazione di malware di sorveglianza chiamato Pegasus Spyware sugli smartphone. Tutto quello che dovevano fare era effettuare una chiamata audio WhatsApp sui numeri di telefono presi di mira.

In pochi semplici passaggi, gli hacker sono stati in grado di entrare nei dispositivi degli utenti e accedervi da remoto.

Migliori pratiche da evitare:

• Secondo le pratiche di codifica sicura OWASP , il codice dovrebbe essere riscritto nel dispositivo mobile invece di fissarlo sul lato server. Gli sviluppatori devono notare che una cattiva codifica sul lato server è molto diversa dalla scarsa codifica a livello di client. Ciò significa che sia i controlli lato server deboli che i controlli lato client dovrebbero ricevere un'attenzione separata.
• Lo sviluppatore deve utilizzare strumenti di terze parti per l'analisi statica per identificare gli overflow del buffer e le perdite di memoria.
• Il team deve creare un elenco di librerie di terze parti e verificarlo periodicamente per le versioni più recenti.
• Gli sviluppatori dovrebbero vedere tutti gli input del client come non attendibili e convalidarli indipendentemente dal fatto che provengano dagli utenti o dall'app.

M8: Rischi di manomissione del codice

Di solito, in questo caso, un utente malintenzionato sfrutta la modifica del codice tramite forme dannose delle app ospitate negli app store di terze parti. Potrebbero anche indurre gli utenti a installare un'applicazione tramite attacchi di phishing.

Migliori pratiche da evitare:

• Gli sviluppatori devono assicurarsi che l'app sia in grado di rilevare le modifiche al codice in fase di esecuzione.
• Il file build.prop deve essere verificato per la presenza di ROM non ufficiali in Android e per scoprire se il dispositivo è rootato.
• Lo sviluppatore deve utilizzare i checksum e valutare le firme digitali per verificare se si è verificata una manomissione del file.
• Il codificatore può assicurarsi che le chiavi dell'app, il codice e i dati vengano rimossi una volta rilevata la manomissione.

M9: Rischio di reverse engineering

Un utente malintenzionato in genere scarica l'app mirata dall'app store e la analizza all'interno del proprio ambiente locale con una suite di strumenti diversi. Successivamente, sono in grado di modificare il codice e rendere diversa la funzione dell'app.

Caso nel mondo reale :

Pokemon Go ha recentemente affrontato gli sguardi di violazione della sicurezza quando è stato scoperto che gli utenti avevano decodificato l'app per conoscere la vicinanza dei Pokemon e catturarli in pochi minuti.

Migliori pratiche da evitare:

• Il modo migliore per salvaguardare un'app dal rischio, secondo OWASP mobile security , è utilizzare gli stessi strumenti che gli hacker userebbero per il reverse engineering.
• Lo sviluppatore deve anche offuscare il codice sorgente in modo che diventi difficile da leggere e quindi decodificare.

M10: Rischio di funzionalità estranea

Di solito, un hacker esamina le funzionalità estranee all'interno di un'app mobile per scoprire le funzionalità nascoste nei sistemi di back-end. L'attaccante sfrutterebbe funzionalità estranee dai propri sistemi senza il coinvolgimento degli utenti finali.

Caso nel mondo reale :

L'idea dell'app Wifi File Transfer era quella di aprire la porta su Android e consentire le connessioni dal computer. Il problema ? Un'assenza di autenticazione come password, il che significa che chiunque potrebbe connettersi a un dispositivo e ottenere il suo pieno accesso.

Migliori pratiche da evitare:

• Assicurati che non ci sia codice di test nella build finale
• Assicurati che non ci siano interruttori nascosti nelle impostazioni di configurazione
• I registri non devono contenere alcuna descrizione del processo del server back-end
• Assicurati che i log di sistema completi non siano esposti alle app dagli OEM
• Gli endpoint API devono essere ben documentati.