Utilizzo di codice nativo
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-26 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-26 UTC."],[],[],null,["# Use of native code\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nAndroid applications can take advantage of native code written in languages like\nC and C++ for specific functionalities. However, when an application utilizes\nthe Java Native Interface (JNI) to interact with this native code, it\npotentially exposes itself to vulnerabilities like buffer overflows and other\nissues that may be present in the native code implementation.\n\nImpact\n------\n\nDespite very positive impacts such as performance optimization and obfuscation,\nutilizing native code in Android applications can have negative security\nimpacts. Native code languages like C/C++ lack the memory safety features of\nJava/Kotlin, making them susceptible to vulnerabilities like buffer overflows,\nuse-after-free errors, and other memory corruption issues -- leading to crashes\nor arbitrary code execution. Additionally, if a vulnerability exists in the\nnative code component, it can potentially compromise the entire application,\neven if the rest is written securely in Java.\n\nMitigations\n-----------\n\n### Development and coding guidance\n\n- **Secure Coding Guidelines**: For C/C++ projects, adhere to established secure coding standards (e.g., CERT, OWASP) to mitigate vulnerabilities like buffer overflows, integer overflows, and format string attacks. Prioritize libraries like Abseil known for quality and security. Whenever possible, consider adopting memory-safe languages like Rust, which offer performance comparable to C/C++.\n- **Input Validation**: Rigorously validate all input data received from external sources, including user input, network data, and files, to prevent injection attacks and other vulnerabilities.\n\n### Harden the compilation options\n\nNative libraries utilizing the ELF format can be hardened against a range of\nvulnerabilities by activating protective mechanisms like stack protection\n(Canary), relocation read-only (RELRO), data execution prevention (NX), and\nposition-independent executables (PIE). Conveniently, the Android NDK\ncompilation options already enable all these protections by default.\n\nTo verify the implementation of these security mechanisms within a binary, you\ncan employ tools like `hardening-check` or `pwntools`. \n\n### Bash\n\n $ pwn checksec --file path/to/libnativecode.so\n Arch: aarch64-64-little\n RELRO: Full RELRO\n Stack: Canary found\n NX: NX enabled\n PIE: PIE enabled\n\n### Verify third-party libraries are not vulnerable\n\nWhen choosing third-party libraries, prioritize using those with a solid\nreputation in the development community. Resources like the [Google Play SDK\nIndex](https://play.google.com/sdks) can help you identify well-regarded and trustworthy libraries. Ensure\nyou keep the libraries updated to the latest versions and proactively search for\nany known vulnerabilities related to them using resources like the databases\nfrom [Exploit-DB](https://www.exploit-db.com/). A web search using keywords like\n`[library_name] vulnerability` or `[library_name] CVE` can reveal critical\nsecurity information.\n\nResources\n---------\n\n- [CWE-111: Direct Use of Unsafe JNI](https://cwe.mitre.org/data/definitions/111.html)\n- [Exploit database](https://www.exploit-db.com/)\n- [Check binaries for security hardening features](https://www.systutorials.com/docs/linux/man/1-hardening-check/)\n- [Check binary security settings with pwntools](https://docs.pwntools.com/en/stable/commandline.html#pwn-checksec)\n- [Linux binary security hardening](https://medium.com/@n80fr1n60/linux-binary-security-hardening-1434e89a2525)\n- [Hardening ELF binaries using Relocation Read-Only (RELRO)](https://www.redhat.com/fr/blog/hardening-elf-binaries-using-relocation-read-only-relro)\n- [OWASP binary protection mechanisms](https://mas.owasp.org/MASTG/Android/0x05i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms)\n- [SEI CERT Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards)\n- [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/release/)\n- [Google Play SDK Index](https://play.google.com/sdks)\n- [Android NDK](/ndk)\n- [Android Rust introduction](https://source.android.com/docs/setup/build/rust/building-rust-modules/overview)\n- [Abseil (C++ Common Libraries)](https://github.com/abseil/abseil-cpp)\n- [PIE is enforced by the linker](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=425?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain)"]]