Metodologia OWASP

** Updated Sep. 2025 **

Il Mobile Application Security Verification Standard (MASVS) 2.0.0, rilasciato nell’aprile 2023, ha eliminato i tre livelli di verifica (L1, L2, R) sostituendoli con “security testing profiles” più granulari:

https://mas.owasp.org

Le aree chiave della sicurezza di un’applicazione mobile sono le seguenti:

• MASVS-STORAGE: Secure data storage
• MASVS-CRYPTO: Cryptographic functionality
• MASVS-AUTH: Authentication and Authorization
• MASVS-NETWORK: Secure communication
• MASVS-PLATFORM: Platform interaction
• MASVS-CODE: Code Quality and Exploit Mitigation
• MASVS-RESILIENCE: Anti-Tampering, Anti-Reversing & Resilience
• MASVS-PRIVACY: Permissions, Management of data & user protection

OWASP Mobile TOP 10 – 2024

• M1: Improper Credential Usage
• M2: Inadequate Supply Chain Security
• M3: Insecure Authentication/Authorization
• M4: Insufficient Input/Output Validation
• M5: Insecure Communication
• M6: Inadequate Privacy Controls
• M7: Insufficient Binary Protections
• M8: Security Misconfiguration
• M9: Insecure Data Storage
• M10: Insufficient Cryptography

M1. Improper Credential Usage

Gestione inadeguata delle credenziali, come hardcoded credentials o trasmissione/salvataggio non sicuri, che permette ad un attaccante di ottenere accesso non autorizzato a funzionalità o dati sensibili dell’app.

M2. Inadequate Supply Chain Security

Vulnerabilità nella supply chain del software mobile, inclusa l’iniezione di codice malevolo durante lo sviluppo o utilizzo di librerie di terze parti non affidabili, che consente compromissioni profonde dell’app e del backend.

M3. Insecure Authe​ntication/Authorization

Schemi di autenticazione e autorizzazione deboli o mancanti, sia lato client che server, che permettono bypass del login o escalation di privilegi.

M4. Insufficient Input/Output Validation​

Mancata o insufficiente validazione e sanificazione di dati in ingresso e in uscita, esponendo l’app a injection (SQLi, command injection), XSS, path traversal etc.

M5. Insecure Communication

Trasmissione di dati in chiaro o uso improprio di protocolli crittografici (SSL/TLS mal configurato, assenza di certificate pinning), che espone a intercettazioni e man-in-the-middle.

M6. Inadequate Privacy Controls​

Trattamento eccessivo o non necessario di PII senza protezioni adeguate (anonymization, minimization, access control), violando regolamentazioni come GDPR e aprendo a furto o abuso dei dati personali.

M7. Insufficient Binary Protections

Mancanza di contromisure contro reverse engineering e code tampering (obfuscation, integrity checks), che facilita l’estrazione di chiavi cablate e la modifica indebita del comportamento dell’app.

M8. Security Misconfiguration

Impostazioni di sicurezza errate o permissive (debug abilitato, backup consentito, permission over-granting), che creano vie di attacco semplici e facilmente individuabili.

M9. Insecure Data Storage

Archiviazione di dati sensibili in chiaro o in posizioni non protette (SharedPreferences, SQLite, file system), che consente estrazione e manipolazione dei dati da parte di malintenzionati.

M10. Insufficient Cryptography

Utilizzo di algoritmi deboli o implementazioni crittografiche errate (chiavi corte, RNG insicuro, hashing senza salt), che compromettono la confidenzialità e l’integrità delle informazioni protette.

Riferimenti: https://owasp.org/www-project-mobile-top-10/

Tipologia di APP

App Native

Android dispone di una SDK e le app native di android sono quelle sviluppate in Java o Kotlin. È disponibile anche la NDK che, attraverso JNI (Java Native Interface) permette di integrare porzioni di app scritte in C/C++.

Pro: Velocità/Reattività, accesso all’hardware, notifiche push, funzionamento offline.

Contro: Non è multipiattaforma

Web App

Sono progettate per sembrare native ma di fatto si appoggiano al browser web. Sono sviluppate in HTML5 e hanno un’icona che non è altro che un bookmark che apre il browser.

Pro: Multipiattaforma, tempi di sviluppo più brevi, non passano dal playstore.

Contro: Non hanno accesso all’hardware, no notifiche push.

App Ibride

Si eseguono alla stessa maniera delle app native ma la maggior parte dei processi fa affidamento al browser. Le app Ibride sono quelle realizzate con Cordova, Ionic, React Native etc.

Pro: Multipiattaforma, hanno accesso all’hardware del device, notifiche push, costi e tempi di sviluppo.

Contro: Performance inferiori, stabilità.

Android Security Architecture

L’architettura di Android si basa su kernel Linux e può essere idealmente suddivisa in 5 diversi layer:

Alla base dell’architettura c’è il kernel Linux che contiene tutti i drivers e fornisce accesso all’hardware. Sopra al kernel c’è l’HAL, un’interfaccia standard che permette agli sviluppatori di far comunicare il software con l’hardware. Poi c’è il layer che contiene tutte le librerie native di C/C++ (es. libc di linux, che però su android si chiama bionic). Le librerie degne di nota sono le seguenti:

• Surface manager: Gestisce le finestre e le schermate.
• Media Framework: Permette l’utilizzo dei codecs per la riproduzione e la registrazione audio/video.
• SQLite: Database.
• WebKit: Browser engine.
• OpenGL: Scritte in C e C++ servono per renderizzare a schermo contenuti 2D e 3D.

Sullo stesso layer delle librerie native si trovano i componenti della runtime di Android. Fino alla versione 4.4 di Android era presente esclusivamente la Dalvik Virtual Machine (DVM) che nelle versioni attuali di Android (dalla 5.0 “Lollipop”) è stata sostituita da Android RunTime (ART).

La differenza sostanziale tra le 2 runtime è che la prima utilizza un tipo di compilazione Just-In-Time (JIT), al momento dell’esecuzione dell’app e la seconda Ahead-of-time (AOT), durante l’installazione.

Il Layer Java Api Framework espone delle classi per gestire dei servizi ad alto livello come le activities, content providers etc.

• Activity Manager: Gestisce il ciclo di vita dell’app.
• Activities: schermate dell’app.
• Content Provider: Permette lo scambio di dati tra le applicazioni. I dati possono essere salvati nel filesystem, in database SQLite, sul web etc e tramite il content provider, altre app possono accedere o modificare tali dati.
• Resource Manager: Fornisce accesso a tutto ciò che non è codice come stringhe, impostazioni colori, layout interfacce etc.
• Notification Manager: Permette all’app di mostrare le notifiche.
• View System: Insieme di viste utilizzate per creare la UI.
• Package Manager: Il servizio con cui le app sono in grado di ottenere info sulle altre app installate sul dispositivo.
• Telephony Manager: Fornisce info in merito ai servizi di chiamata, sms e simili.
• Location Manager: Fornisce accesso ai servizi di localizzazione.

In cima a tutti i layer si trovano le applicazioni installate sul device.

APP Sandbox

L’esecuzione di ogni applicazione Android avviene nella propria sandbox, ciascun’ applicazione è isolata dalle altre e da tutti gli altri processi facendo leva sul sistema ormai collaudato dei permessi multiutente di Linux (DAC). Praticamente Android assegna un UID unico ad ogni applicazione che poi verrà eseguita nel contesto di quell user ID / group ID.

Dal momento che la sandbox è gestita dal kernel attraverso i permessi di linux, è importante notare come tutto ciò che sta sopra, tutte le librerie incluse dall’applicazione, api e framework, ereditano i permessi concessi all’app.

Ad ogni modo Android nel corso del tempo ha implementato ulteriori protezioni oltre a DAC, ha introdotto SELinux, ha limitato l’accesso alle app ad alcune chiamate di sistema, ha limitato l’accesso al filesystem etc.