Categoria OWASP: MASVS-CODE: Code Quality
Panoramica
Il rilascio di build di produzione che includono funzionalità di test o debug può influire negativamente sulla postura di sicurezza dell'applicazione. Queste funzionalità vengono utilizzate per aiutare gli sviluppatori a scoprire e identificare bug all'interno dei casi d'uso previsti dell'applicazione prima o dopo il rilascio di una nuova versione e non devono essere accessibili pubblicamente.
Esempi di funzionalità di test/ debug sono:
- Menu nascosti
- Opzioni per abilitare i log di debug
- Opzioni per modificare il flusso dell'applicazione
- Opzioni per aggirare le procedure di pagamento o di abbonamento
- Opzioni per aggirare l'autenticazione
- Test per attività specifiche dell'applicazione
Tutto ciò che precede può essere sfruttato da un utente malintenzionato per alterare il flusso previsto dell'applicazione o recuperare informazioni di sistema per personalizzare ulteriormente gli attacchi.
Il rischio introdotto lasciando esposte le funzionalità di test o debug può variare a seconda dell'azione associata alle funzionalità di debug stesse.
Un altro ambito di rischio per l'applicazione è l'attributo android:debuggable
impostato all'interno dell'elemento <application>
del file AndroidManifest.xml. Come riportato nell'articolo
android:debuggable,
il deployment di un'applicazione di produzione con il valore sopra menzionato consente
agli utenti malintenzionati di accedere a risorse amministrative altrimenti
inaccessibili.
Impatto
Un utente malintenzionato che interagisce con una funzionalità di test o di debug in una build di produzione può portare a risultati imprevisti. L'impatto di qualsiasi azione è direttamente collegato alle autorizzazioni assegnate alla funzionalità. Più elevati sono i permessi, maggiore è l'impatto che può avere un'exploit attiva. Queste funzionalità all'interno di un'applicazione possono essere utilizzate per aggirare una serie di protezioni, bypassare i paywall, recuperare informazioni relative al sistema o all'utente o attivare attività di test.
Mitigazioni
Evita di utilizzare i componenti di debug
Le funzionalità di test o debug non devono mai essere implementate all'interno di componenti dell'applicazione di produzione come attività, ricevitori di trasmissione, servizi o fornitori di contenuti, poiché, se esportate, possono essere eseguite da qualsiasi altro processo sul dispositivo. L'impostazione del componente di debug come non esportato (android:exported="false") non costituisce una protezione valida per le funzionalità, in quanto qualsiasi dispositivo rooted può comunque eseguirle tramite lo strumento Android Debug Bridge (ADB) se l'opzione di debug è attivata.
Limitare le funzionalità di debug o di test alle build di staging
L'esecuzione di qualsiasi funzione di test o debug all'interno delle applicazioni deve essere limitata solo a un insieme ristretto di build di staging per consentire solo agli sviluppatori di eseguire il debug o testare le funzionalità dell'applicazione in un ambiente controllato. Puoi ottenerlo creando una build di test o di debug dedicata dell'applicazione e test strumentati avanzati per assicurarti che qualsiasi funzionalità di test o di debug venga eseguita su una versione isolata.
Implementare test automatici dell'interfaccia utente
Quando esegui test su un'applicazione, scegli test automatici dell'interfaccia utente, poiché sono ripetibili, possono essere eseguiti in un ambiente separato e non sono soggetti a errori umani.
Risorse
- Guida per gli sviluppatori sulle configurazioni di test avanzate
- Guida per gli sviluppatori sull'automazione dei test dell'interfaccia utente
- android:debuggable
- android:exported
- App di cui è possibile eseguire il debug in Android Market
- Il codice di debug può causare vulnerabilità della sicurezza?