استفاده از کد بومی
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
دسته OWASP: MASVS-CODE: کیفیت کد
نمای کلی
برنامه های اندروید می توانند از کدهای بومی نوشته شده به زبان هایی مانند C و C++ برای عملکردهای خاص بهره ببرند. با این حال، هنگامی که یک برنامه از رابط بومی جاوا (JNI) برای تعامل با این کد بومی استفاده می‌کند، به طور بالقوه خود را در معرض آسیب‌پذیری‌هایی مانند سرریز بافر و سایر مسائلی که ممکن است در پیاده‌سازی کد بومی وجود داشته باشد، قرار می‌دهد.
تاثیر
علیرغم تأثیرات بسیار مثبتی مانند بهینه سازی عملکرد و مبهم سازی، استفاده از کد بومی در برنامه های اندروید می تواند تأثیرات امنیتی منفی داشته باشد. زبان‌های کد بومی مانند C/C++ فاقد ویژگی‌های ایمنی حافظه جاوا/کوتلین هستند، که آنها را مستعد آسیب‌پذیری‌هایی مانند سرریز شدن بافر، خطاهای استفاده پس از آزادسازی و سایر مشکلات خرابی حافظه می‌کند که منجر به خرابی یا اجرای کد دلخواه می‌شود. علاوه بر این، اگر آسیب‌پذیری در مؤلفه کد اصلی وجود داشته باشد، می‌تواند به طور بالقوه کل برنامه را به خطر بیندازد، حتی اگر بقیه به طور ایمن در جاوا نوشته شده باشند.
اقدامات کاهشی
راهنمای توسعه و کدنویسی
- دستورالعمل‌های کدگذاری امن : برای پروژه‌های C/C++، استانداردهای کدگذاری ایمن (مانند CERT، OWASP) را رعایت کنید تا آسیب‌پذیری‌هایی مانند سرریز بافر، سرریز اعداد صحیح و حملات رشته‌ای قالب‌بندی را کاهش دهید. کتابخانه هایی مانند Abseil که به دلیل کیفیت و امنیت شناخته شده است را در اولویت قرار دهید. در صورت امکان، زبان‌های ایمن برای حافظه مانند Rust را در نظر بگیرید که عملکردی قابل مقایسه با C/C++ دارند.
- اعتبارسنجی ورودی : برای جلوگیری از حملات تزریق و سایر آسیب‌پذیری‌ها، تمام داده‌های ورودی دریافتی از منابع خارجی، از جمله ورودی کاربر، داده‌های شبکه و فایل‌ها را به‌شدت تأیید کنید.
گزینه های کامپایل را سخت کنید
کتابخانه‌های بومی با استفاده از فرمت ELF می‌توانند با فعال کردن مکانیسم‌های حفاظتی مانند حفاظت پشته (Canary)، جابجایی فقط خواندنی (RELRO)، جلوگیری از اجرای داده‌ها (NX) و فایل‌های اجرایی مستقل از موقعیت (PIE) در برابر طیف وسیعی از آسیب‌پذیری‌ها سخت‌تر شوند. به‌راحتی، گزینه‌های کامپایل Android NDK در حال حاضر همه این حفاظت‌ها را به‌طور پیش‌فرض فعال می‌کنند.
برای تأیید اجرای این مکانیسم‌های امنیتی در یک باینری، می‌توانید از ابزارهایی مانند hardening-check یا pwntools استفاده کنید.
ضربه شدید
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
بررسی کنید که کتابخانه های شخص ثالث آسیب پذیر نیستند
هنگام انتخاب کتابخانه‌های شخص ثالث، استفاده از کتابخانه‌هایی که شهرت خوبی در جامعه توسعه دارند، در اولویت قرار دهید. منابعی مانند Google Play SDK Index می تواند به شما در شناسایی کتابخانه های معتبر و قابل اعتماد کمک کند. اطمینان حاصل کنید که کتابخانه ها را به آخرین نسخه ها به روز نگه می دارید و با استفاده از منابعی مانند پایگاه داده های Exploit-DB، هر گونه آسیب پذیری شناخته شده مربوط به آنها را به طور فعال جستجو کنید. جستجوی وب با استفاده از کلمات کلیدی مانند [library_name] vulnerability یا [library_name] CVE می‌تواند اطلاعات امنیتی مهمی را نشان دهد.
منابع
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)"]]
