Categoria OWASP: MASVS-CODE: Qualità del codice
Panoramica
Le applicazioni Android possono sfruttare il codice nativo scritto in linguaggi come C e C++ per funzionalità specifiche. Tuttavia, quando un'applicazione utilizza la Java Native Interface (JNI) per interagire con questo codice nativo, si espone potenzialmente a vulnerabilità come overflow del buffer e altri problemi che potrebbero essere presenti nell'implementazione del codice nativo.
Impatto
Nonostante gli impatti molto positivi come l'ottimizzazione delle prestazioni e l'oscuramento, l'utilizzo di codice nativo nelle applicazioni Android può avere impatti negativi sulla sicurezza. I linguaggi di codice nativo come C/C++ non dispongono delle funzionalità di sicurezza della memoria di Java/Kotlin, il che li rende suscettibili a vulnerabilità come overflow del buffer, errori use-after-free e altri problemi di danneggiamento della memoria, che possono causare arresti anomali o esecuzione di codice arbitrario. Inoltre, se esiste una vulnerabilità nel componente di codice nativo, può potenzialmente compromettere l'intera applicazione, anche se il resto è scritto in modo sicuro in Java.
Mitigazioni
Informazioni sullo sviluppo e sulla programmazione
- Linee guida per la programmazione sicura: per i progetti C/C++, rispetta gli standard di programmazione sicura stabiliti (ad es. CERT, OWASP) per mitigare vulnerabilità come overflow del buffer, overflow di interi e attacchi di stringhe di formato. Dai la priorità alle librerie, come Abseil, note per la qualità e la sicurezza. Se possibile, valuta la possibilità di adottare linguaggi sicuri per la memoria come Rust, che offrono prestazioni paragonabili a C/C++.
- Convalida dell'input: convalida rigorosamente tutti i dati di input ricevuti da fonti esterne, inclusi input utente, dati di rete e file, per evitare attacchi di inserimento e altre vulnerabilità.
Rafforzare le opzioni di compilazione
Le librerie native che utilizzano il formato ELF possono essere rese più resistenti a una serie di vulnerabilità attivando meccanismi di protezione come la protezione dello stack (Canary), la sola lettura della ricollocazione (RELRO), la prevenzione dell'esecuzione dei dati (NX) e gli eseguibili indipendenti dalla posizione (PIE). Comodamente, le opzioni di compilazione NDK di Android abilitano già tutte queste protezioni per impostazione predefinita.
Per verificare l'implementazione di questi meccanismi di sicurezza all'interno di un file binario, puoi utilizzare strumenti come hardening-check
o pwntools
.
Bash
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Verificare che le librerie di terze parti non siano vulnerabili
Quando scegli le librerie di terze parti, dai la priorità a quelle con una solida reputazione nella community di sviluppo. Risorse come l'SDK Google Play
Index possono aiutarti a identificare librerie affidabili e di buona reputazione. Assicurati di mantenere le librerie aggiornate alle versioni più recenti e di cercare in modo proattivo tutte le vulnerabilità note correlate utilizzando risorse come i database di Exploit-DB. Una ricerca web utilizzando parole chiave come [library_name] vulnerability
o [library_name] CVE
può rivelare informazioni di sicurezza critiche.
Risorse
- CWE-111: Utilizzo diretto di JNI non sicuro
- Database di exploit
- Controllare i file binari per verificare la presenza di funzionalità di rafforzamento della sicurezza
- Controllare le impostazioni di sicurezza dei binari con pwntools
- Ottimizzazione della sicurezza dei binari di Linux
- Ottimizzazione della sicurezza dei binari ELF mediante Relocation Read-Only (RELRO)
- Meccanismi di protezione binaria OWASP
- SEI CERT Coding Standards
- Guida per gli sviluppatori OWASP
- Google Play SDK Index
- Android NDK
- Introduzione ad Android Rust
- Abseil (librerie comuni C++)
- Il PIE viene applicato dal linker