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
- CWE-111: Uso directo de JNI no segura
- Explotar la base de datos
- Revisa los objetos binarios para detectar funciones de endurecimiento de la seguridad
- Cómo verificar la configuración de seguridad binaria con pwntools
- Endurecimiento de la seguridad de los objetos binarios de Linux
- Endurecimiento de objetos binarios ELF con la reubicación de solo lectura (RELRO)
- Mecanismos de protección de objetos binarios de OWASP
- Estándares de codificación de SEI CERT
- Guía para desarrolladores de OWASP
- Índice SDK de Google Play
- NDK de Android
- Introducción a Rust para Android
- Abseil (bibliotecas comunes de C++)
- El vinculador aplica el PIE