Downloaded 10 times
Uploaded byCodemotion
Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri
Il documento tratta delle vulnerabilità e delle minacce nella sicurezza delle applicazioni mobili, evidenziando l'evoluzione degli attacchi informatici nel corso degli anni. Viene presentata una lista di problemi comuni nelle app mobili e suggerimenti per migliorarne la sicurezza, come l'uso dei controlli lato server e la protezione dei dati memorizzati. Viene inoltre menzionato il ruolo di OWASP nella definizione delle migliori pratiche per la sicurezza delle applicazioni mobili.
More Related Content
Similar to Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri
Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri
- 1. ROME 11-12 april2014ROME 11-12 april 2014 Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile simone.onofri@techub.it Simone Onofri
- 2.
- 4.
- 5. Agenda • Introduzione •Cosa succede nel mondo della sicurezza del mobile • Quali sono gli a5acchi e le minacce? • Cosa ne pensa OWASP? • Come rendere sicure le nostre applicazioni mobile • Q&A e Conclusioni
- 6. Agenda • Introduzione •Cosa succede nel mondo della sicurezza del mobile • Quali sono gli a5acchi e le minacce? • Cosa ne pensa OWASP? • Come rendere sicure le nostre applicazioni mobile • Q&A e Conclusioni
- 7.
- 8. Cosa succede nel mondo?
- 9. Computer Security Timeline 1970 Nei primi anni nasce il primo Virus, infe5a gli Apple e si diffonde tramite Floppy. Negli ulAmi anni nascono i Worm, alcuni dei quali cifrano il disco. A,acchi alle PA. 1980 1990 Blue Box Phreaking da Capitan Crunch. A5acchi alle compagnie telefoniche. Il mezzo di propagazione è spesso l’e-‐mail e i bersagli sono i sistemi operaAvi MicrosoI (a5accando es. Outlook express). Il bersaglio sono le persone.
- 10. Computer Security Timeline 2000 Si denunciano Advanced Persistent Threat. I disposiAvi mobile diventano un bersaglio Apico. Sono molto frequenA a5acchi a sfondo poliQco. Diventa evidente come quesA strumenA siano usaQ come armi. 2010 I Virus a5accano anche i servizi di rete (es. Slammer, Sasser e Blaster). Iniziano gli a5acchi alle Applicazioni Web e su SCADA. L’obieQvo è anche creare disservizi. E’ a tuQ gli effeQ un Business.
- 11. Aumenta la sofisAcazione degli a,acchi che mirano a creare un disservizio e di quelli che hanno come bersaglio le applicazioni web.
- 12. A5acchi frequenA sono ai disposiAvi Mobile, bersaglio di malware per rubare conQ o transazioni bancarie, daQ di accesso (social, e-‐mail). Furto di idenQtà e di daA più in generale.
- 13. Sopra5u5o sul sistema operaAvo Android. Ne è moAvo la forte diffusione e il fa5o che non sono spesso distribuiQ tempesQvamente gli aggiornamenQ di sicurezza da parte dei provider che “brandizzano” il disposiAvo
- 14. Aumenta la sofisAcazione degli a,acchi che mirano a creare un disservizio e di quelli che hanno come bersaglio le applicazioni.
- 15. gli a5accanA tendono a sfru5are vulnerabilità che sono presenA a causa di praQche di sicurezza basilari inadeguate
- 16. app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app Circa la metà delle applicazioni web hanno vulnerabilità importanA secondo l’X-‐Force 50%
- 17. app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app app Quasi tu5e le applicazioni sono vulnerabili secondo il report CENZIC 99%
- 18. Le principali problemaQche delle applicazioni mobile
- 19. La TOP 10 Risk Mobile (2013 vs 2014 RC1) M1:Insecure Data Storage M2:Weak Server Side Controls M3:Insufficient Transport Layer ProtecQon M4: Client Side InjecQon M5: Poor AuthorizaQon and AuthenQcaQon M6: Improper Session Handling M7: Security Decisions Via Untrusted Inputs M8: Side Channel Data Leakage M9: Broken Cryptography M10: SensiQve InformaQon Disclosure M1: Weak Server Side Controls M2: Insecure Data Storage M3:Insufficient Transport Layer ProtecQon M4: Unintended Data Leakage M5: Poor AuthorizaQon and AuthenQcaQon M6: Broken Cryptography M7: Client Side InjecQon M8: Security Decisions via Untrusted Inputs M9: Improper Session Handling M10: Lack of Binary ProtecQon
- 20. Il nostro disposiQvo mobile Hardware Sistema OperaQvo RunQme Applicazioni Aziendali Personali Bult-‐in Malicious Librerie Dipendenze VM Kernel Driver File System Radio GPS Sensori Estensioni hardware Le,ori/ Sensori 802.11 / NFC / Bluetooth Peer Rete del Carrier SMS Voce DaQ WiFi /VPN (o via Carrier) Web M2: Insecure Data Storage M1: Weak Server Side Controls M3: Insufficient Transport Layer ProtecQon M8: Security Decisions via Untrusted Inputs M5: Poor AuthorisaQon and AuthenQcaQon M6: Broken Cryptography M7: Client Side InjecQon M4: Unintended Data Leakage M9: Improper Session Handling M10: Lack of Binary ProtecQon
- 21. Come rendere sicure le nostre applicazioni mobile
- 22. M1. Weak Server Side Controls Sono quelle problemaAche che dipendono dai servizi che uQlizza l’applicazione mobile, come il servizio web uAlizzato (Web Service, REST, SOAP). Se la nostra applicazione uAlizza servizi esterni anche quesA devono essere sicuri e non dobbiamo solamente concentrarci sulle problemaAche dell’applicazione in se. Gli a,accanQ non fanno troppe disQnzioni tra vulnerabilità web, Mobile o di sistema ma sfru,eranno quella più semplice.
- 23. Riflessioni e SuggerimenQ •UAlizziamo servizi Web? Facciamo riferimento alla OWASP TOP 10 Web (almeno per iniziare). • UAlizziamo servizi Cloud? Facciamo riferimento alla TOP 10 Cloud.
- 24. 2003/2004 (a,acks) 2007 (vulnerabiliQes) 2010 (risks) 2013 (risks) Unvalidated Input Cross Site ScripQng (XSS) InjecQon InjecQon Broken Access Control InjecQon Flaws Cross-‐Site ScripQng (XSS) Broken AuthenQcaQon and Session Management Broken AuthenQcaQon and Session Management Malicious File ExecuQon Broken AuthenQcaQon and Session Management Cross-‐Site ScripQng (XSS) Cross Site ScripQng (XSS) Flaws Insecure Direct Object Reference Insecure Direct Object References Insecure Direct Object References Buffer Overflows Cross Site Request Forgery (CSRF)* Cross-‐Site Request Forgery (CSRF) Security MisconfiguraQon InjecQon Flaws InformaQon Leakage and Improper Error Handling Security MisconfiguraQon SensiQve Data Exposure Improper Error Handling Broken AuthenQcaQon and Session Management Insecure Cryptographic Storage Missing FuncQon Level Access Control Insecure Storage Insecure Cryptographic Storage Failure to Restrict URL Access Cross-‐Site Request Forgery (CSRF) Denial of Service Insecure CommunicaQons Insufficient Transport Layer ProtecQon Using Known Vulnerable Components Insecure ConfiguraQon Management Failure to Restrict URL Access Unvalidated Redirects and Forwards Unvalidated Redirects and Forwards
- 25. M2. Insecure Data Storage Sono quelle problemaAche di protezione dei daQ memorizzaQ. Si concreAzzano quando viene compromesso il disposiAvo tramite applicazioni malevoli oppure in caso di furto. Se ci sono delle informazioni riservate (es. password, CVV2, daA privaA) devono essere proteQ.
- 26. Riflessioni e SuggerimenQ •Se il disposiAvo viene rubato, oppure è presente un trojan o altra applicazione malevola la nostra applicazione deve proteggere i daA che gesAsce. • Fare a5enzione a quando si memorizzano informazioni su: • Database SQLite • File di Log • Plist • XML • File Manifest • Storage di altro Apo su file • Cookie • Schede SD
- 27. M3. Insufficient Transport Layer ProtecQon Sono quelle problemaAche relaAve alla sicurezza della comunicazione, perme5ono di interce5are il traffico tra l’utente e il server o tra server differenA. Come per le altre vulnerabilità il problema potrebbe consistere o nella mancanza del controllo stesso (come l’uAlizzo di HTTP) o nelle problemaAche di configurazione di SSL/TLS sia lato server ma in parAcolare lato disposiAvo mobile.
- 28. Riflessioni e SuggerimenQ •Tipicamente un disposiAvo mobile viene uAlizzato tramite la rete del Carrier (di cui ci fidiamo?) oppure tramite reA Wireless casalinghe oppure gratuite (anche in Italia cominciano a diffondersi) • Dobbiamo proteggere l’applicazione: • Tramite il server (configurandolo corre5amente e tenendolo aggiornato) • Tramite l’applicazione (validare e acce5are solamente cerAficaA trusted)
- 29.
- 30. M4. Unintended Data Leakage Prima chiamata Side-‐Channel Data Leakage è una so,o-‐categoria della più completa Insecure Data Storage, riguarda dove vengono salvaA i daA. Sono quelle problemaAche che rendono accessibili informazioni che invece dovrebbero essere prote5e. Solitamente generata da un uAlizzo non corre5o del Sistema OperaAvo, di Framework, Compilatori senza che gli sviluppatori ne siano a conoscenza.
- 31. Riflessioni e SuggerimenQ •E’ possibile che librerie, framework o il sistema operaAvo salvino in qualche locazione non prote5a informazioni sensibili. Bisogna fare a5enzione a: • Caching delle richieste/risposte HTTP e dei Cookie • Caching della tasAera • Sistemi che mantengono i Log o che inviano staAsAche • Storage di HTML5
- 32. A5. Poor AuthorizaQon and AuthenQcaQon Sono quelle problemaAche che riguardano AutenQcazione e Autorizzazione, elemenA cruciali in parAcolare per le applicazioni mobile. Secondo la stru5ura dell’applicazione quesA due controlli potrebbero essere gesAA dire5amente sul disposiAvo oppure, se l’applicazione si collega a dei servizi web, devono essere gesAA dire5amente lato server. Inoltre è importante la scelta dei vari criteri da uAlizzaA per idenAficare (e quindi poi autenAcare l’utente).
- 33. Riflessioni e SuggerimenQ •GesAre sempre l’autenAcazione e l’autorizzazione lato server, e fornire i daA solo previa verifica. • Se bisogna memorizzare delle informazioni sul disposiAvo e prevedere più utenA allora cifrare le informazioni così da non renderle accessibili. • A5enzione alle funzionalità di “Ricordami” e al salvataggio dei Token di autenAcazione. • Non uAlizzare informazioni che possono essere alterate per l’autenAcazione (es. device id, caller id).
- 34. M6. Broken Cryptography Questa problemaAca relaAva alla protezione delle informazioni memorizzate, consiste nell’uAlizzo di algoritmi cri5ografici non sicuri o uAlizzaA in maniera errata. Gli algoritmi uAlizzaA devono essere infaQ consideraA sicuri dalla comunità ed essere uAlizzaA corre5amente.
- 35. Riflessioni e SuggerimenQ •Quando si uAlizzano elemenA cri5ografici dobbiamo: • Usare solamente algoritmi consideraQ sicuri (es. evitare MD5, SHA1) • UAlizzarli in maniera propria (es. Password con gli hash e non con cifratura simmetrica) • GesAre corre5amente le chiavi cri5ografiche e i cerAficaA.
- 36. M7. Client Side InjecQon Questa problemaAca apparAene alla validazione dei daQ, in quanto l’applicazione interagisce con l’esterno a5raverso dei daA. Può ricevere daA dall’utente come da altre enAtà come sensori, hardware, database interni o dire5amente dal nostro web server. QuesA daA possono essere manipolaA più o meno facilmente e pertanto devono essere verificaA per evitare comportamenA anomali dell’applicazione.
- 37. Riflessioni e SuggerimenQ •Quando riceviamo daA dall’utente o da fonA esterne all’applicazione, anche quelli memorizzaA all’interno di un database locale dobbiamo sempre considerare che possiamo ricevere daA alteraA e fare a5enzione ai daA che sono uAlizzaA da: • Database, per le SQL InjecAon • File System, per le File Inclusion • InterpreA più in generale (XML, Xpath, Xquery…) e anche funzioni matemaAche. • UAlizziamo HTML5? h5p://onofri.org/u/html5sec
- 38. M8. Security Decisions via Untrusted Inputs L’applicazione potrebbe interagire con i processi esterni, esempio tramite l’Inter-‐Process CommunicaAon (IPC) di iOS. Oppure su Android altre applicazioni potrebbero avere i permessi per accedere ad alcune componenA. Tali interazioni devono essere sempre verificate.
- 39. Riflessioni e SuggerimenQ •L’applicazione può acce5are daA ed essere uAlizzata anche da altre applicazioni: l’accesso a tale componenA devono essere gesAte corre5amente. • Ad esempio su iOS: • NON uAlizzare handleOpenURL ma openURL, uAlizzando una whitelist per le applicazioni. NON uAlizzare la Pasteboard per le comunicazioni IPC. • Su Android configurare corre5amente AndroidManifest.xml: per le componenA private uAlizzare android:exported=false, per le altre uAlizzare true ma specificare l’android:permission.
- 40. M9. Improper Session Handling HTTP è un protocollo state-‐less e per mantenere la sessione aQva tra Client e Server viene stabilita una sessione a5raverso l’uAlizzo di Cookie o di Token univoci. La sessione deve essere prote5a sia lato server, come indicato in M1, sia lato Client con dovuA accorgimenA sia per quel che riguarda la protezione del Cookie e/o del Token che per quel che riguarda la gesAone delle informazioni contenute all’interno della sessione che devono essere distru5e quando la sessione termina. Lo stesso Ameout della sessione (assoluto e relaAvo) deve essere ben definito e coerente con il contesto.
- 41. Riflessioni e SuggerimenQ •La gesAone della sessione è un elemento Apicamente criQco, in parAcolare se la nostra applicazione manQene aqva la sessione verso il web server. La sessione deve essere gesAta corre5amente lato server (come specificato per M1), ma anche lato client distruggendo corre5amente i daA alla fine della sessione. • Deve essere specificato un Qmeout assoluto (tempo di vita massimo) e relaAvo (dall’ulAmo uAlizzo) in coerenza con il contesto applicaAvo. • I Cookie o più in generale i Token di sessione devono essere gesQQ corre,amente (es. cambiaA ad ogni login e devono essere abbastanza complessi e casuali da resistere ad a5acchi di cri5oanalisi o brute-‐force).
- 42. M10. Lack of Binary ProtecQon L’applicazione stessa deve essere prote5a come anche il suo codice sorgente. Il disposiAvo mobile deve essere considerando un “ambiente osAle” per la nostra applicazione e dobbiamo proteggerla da eventuali a5acchi come il reverse engineering, la modifica di eventuali componenA (es. file web presenA in locale) o dei binari stessi. Le tecniche per la protezione sono diverse e cambiano da ambiente ad ambiente.
- 43. Riflessioni e SuggerimenQ •Dobbiamo considerare osAle l’ambiente mobile e difendere la nostra applicazione, il suo codice sorgente e i vari elemenA residenA sul disposiAvo uAlizzaA dall’applicazione, ad esempio verificando l’integrità delle componenA uAlizzate o se viene inserito del codice al runAme: • Su iOS verificando se il disposiAvo è stato so5oposto a Jailbreak o se è possible eseguire il dump dell’eseguibile (es. Clutch) • Su Android verificando se il disposiAvo è stato rootato e offuscando il codice.
- 44.
- 45.
- 47. Security User GrOup ! h,ps://groups.google.com/forum/#! forum/sugo
- 48.
- 49.