Uso de código nativo
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Categoría de OWASP: MASVS-CODE: Calidad de código
Descripción general
Las aplicaciones para Android pueden aprovechar el código nativo escrito en lenguajes como C y C++ para funciones específicas. Sin embargo, cuando una aplicación usa la interfaz nativa de Java (JNI) para interactuar con este código nativo, es posible que se exponga a vulnerabilidades como el desbordamiento del búfer y otros problemas que pueden estar presentes en la implementación del código nativo.
Impacto
A pesar de los impactos muy positivos, como la optimización del rendimiento y la ofuscación, el uso de código nativo en aplicaciones para Android puede tener impactos negativos en la seguridad. Los lenguajes de código nativo, como C/C++, carecen de las funciones de seguridad de la memoria de Java/Kotlin, lo que los hace susceptibles a vulnerabilidades, como desbordamientos de búfer, errores de uso después de la liberación y otros problemas de corrupción de memoria, lo que genera fallas o ejecución de código arbitraria. Además, si existe una vulnerabilidad en el componente del código nativo, puede comprometer toda la aplicación, incluso si el resto está escrito de forma segura en Java.
Mitigaciones
Orientación sobre programación y desarrollo
- Lineamientos de codificación segura: En el caso de los proyectos de C/C++, cumple con los estándares de codificación segura establecidos (p.ej., CERT, OWASP) para mitigar vulnerabilidades, como desbordamientos de búfer, desbordamientos de números enteros y ataques de cadenas de formato. Prioriza bibliotecas como Abseil, que se destacan por su calidad y seguridad. Siempre que sea posible, considera adoptar lenguajes seguros para la memoria, como Rust, que ofrecen un rendimiento comparable al de C/C++.
- Validación de entradas: Valida de forma rigurosa todos los datos de entrada recibidos de fuentes externas, incluidas las entradas del usuario, los datos de red y los archivos, para evitar ataques de inyección y otras vulnerabilidades.
Endurece las opciones de compilación
Las bibliotecas nativas que usan el formato ELF se pueden endurecer contra una variedad de vulnerabilidades mediante la activación de mecanismos de protección como la protección de pila (Canary), la reubicación de solo lectura (RELRO), la prevención de ejecución de datos (NX) y los ejecutables independientes de la posición (PIE). Convenientemente, las opciones de compilación del NDK de Android ya habilitan todas estas protecciones de forma predeterminada.
Para verificar la implementación de estos mecanismos de seguridad dentro de un binario, puedes usar herramientas como 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
Verifica que las bibliotecas de terceros no sean vulnerables
Cuando elijas bibliotecas de terceros, prioriza el uso de aquellas con una reputación sólida en la comunidad de desarrollo. Los recursos como el Índice SDK de Google Play pueden ayudarte a identificar bibliotecas respetadas y confiables. Asegúrate de mantener las bibliotecas actualizadas a las versiones más recientes y busca de forma proactiva cualquier vulnerabilidad conocida que esté relacionada con ellas con recursos como las bases de datos de Exploit-DB. Una búsqueda web con palabras clave como [library_name] vulnerability o [library_name] CVE puede revelar información de seguridad crítica.
Recursos
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-26 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
