Utilisation de code natif
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Catégorie OWASP : MASVS-CODE : qualité du code
Présentation
Les applications Android peuvent tirer parti du code natif écrit dans des langages tels que C et C++ pour des fonctionnalités spécifiques. Toutefois, lorsqu'une application utilise Java Native Interface (JNI) pour interagir avec ce code natif, elle s'expose potentiellement à des failles telles que des débordements de tampon et d'autres problèmes pouvant être présents dans l'implémentation du code natif.
Impact
Malgré des impacts très positifs tels que l'optimisation des performances et l'obscurcissement, l'utilisation de code natif dans les applications Android peut avoir des conséquences négatives sur la sécurité. Les langages de code natif tels que C/C++ ne disposent pas des fonctionnalités de sécurité de la mémoire de Java/Kotlin, ce qui les rend vulnérables aux failles telles que les dépassements de mémoire tampon, les erreurs d'utilisation après libération et d'autres problèmes de corruption de mémoire, ce qui entraîne des plantages ou l'exécution de code arbitraire. De plus, si une faille existe dans le composant de code natif, cela peut compromettre l'ensemble de l'application, même si le reste est écrit de manière sécurisée en Java.
Stratégies d'atténuation
Conseils de développement et de codage
- Consignes de codage sécurisé: pour les projets C/C++, respectez les normes de codage sécurisé établies (par exemple, CERT, OWASP) pour atténuer les failles telles que les dépassements de tampon, les dépassements d'entiers et les attaques de chaîne de format. Privilégiez les bibliothèques comme Abseil, réputées pour leur qualité et leur sécurité. Dans la mesure du possible, envisagez d'adopter des langages à mémoire sécurisée comme Rust, qui offrent des performances comparables à celles de C/C++.
- Validation des entrées: validez rigoureusement toutes les données d'entrée reçues de sources externes, y compris les entrées utilisateur, les données réseau et les fichiers, pour éviter les attaques par injection et d'autres failles.
Renforcer les options de compilation
Les bibliothèques natives utilisant le format ELF peuvent être renforcées contre un large éventail de failles en activant des mécanismes de protection tels que la protection de la pile (Canary), la relocation read-only (RELRO), la protection de l'exécution des données (NX) et les exécutables indépendants de la position (PIE). Pratiquement, les options de compilation du NDK Android activent déjà toutes ces protections par défaut.
Pour vérifier la mise en œuvre de ces mécanismes de sécurité dans un binaire, vous pouvez utiliser des outils tels que hardening-check
ou 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
Vérifier que les bibliothèques tierces ne sont pas vulnérables
Lorsque vous choisissez des bibliothèques tierces, privilégiez celles qui jouissent d'une bonne réputation dans la communauté de développement. Des ressources telles que l'index du SDK Google Play peuvent vous aider à identifier des bibliothèques réputées et fiables. Assurez-vous de mettre à jour les bibliothèques vers les dernières versions et recherchez de manière proactive les failles connues qui les concernent à l'aide de ressources telles que les bases de données d'Exploit-DB. Une recherche sur le Web à l'aide de mots clés tels que [library_name] vulnerability
ou [library_name] CVE
peut révéler des informations de sécurité critiques.
Ressources
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/26 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]