שימוש בקוד מקורי
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
קטגוריה ב-OWASP: MASVS-CODE: איכות הקוד
סקירה כללית
אפליקציות ל-Android יכולות להשתמש בקוד מקורי שנכתב בשפות כמו C ו-C++ לצורך פונקציות ספציפיות. עם זאת, כשאפליקציה משתמשת בממשק Java Native Interface (JNI) כדי ליצור אינטראקציה עם הקוד הזה, היא עלולה לחשוף את עצמה לנקודות חולשה כמו זליגת נתונים במאגר (buffer overflow) ובעיות אחרות שעשויות להיות בהטמעה של הקוד.
השפעה
למרות ההשפעות החיוביות מאוד, כמו אופטימיזציה של הביצועים וערפול קוד (obfuscation), לשימוש בקוד מקורי באפליקציות ל-Android יכולות להיות השפעות שליליות על האבטחה. בשפות קוד נייטיב כמו C/C++ חסרות תכונות אבטחת הזיכרון של Java/Kotlin, ולכן הן חשופות לנקודות חולשה כמו גלישת מאגר נתונים זמני, שגיאות שימוש לאחר שימוש ובעיות אחרות של פגיעה בזיכרון, מה שמוביל לקריסות או לביצוע קוד באופן אקראי. בנוסף, אם קיימת נקודת חולשה ברכיב קוד המקור, היא עלולה לפגוע באפליקציה כולה, גם אם השאר נכתב באופן מאובטח ב-Java.
פעולות מיטיגציה
הנחיות לפיתוח ולכתיבת קוד
- הנחיות לכתיבת קוד מאובטח: בפרויקטים של C/C++ צריך לפעול בהתאם לתקני קוד מאובטח מקובלים (למשל, CERT, OWASP) כדי לצמצם נקודות חולשה כמו זליגת נתונים במאגר נתונים זמני, זליגת נתונים במספר שלם והתקפות על מחרוזות פורמט. כדאי לתת עדיפות לספריות כמו Abseil, שנחשבות לאיכותיות ומאובטחות. כשהדבר אפשרי, כדאי להשתמש בשפות ללא בעיות בזיכרון, כמו Rust, שמציעות ביצועים דומים לאלה של C/C++.
- אימות קלט: אימות קפדני של כל נתוני הקלט שמתקבלים ממקורות חיצוניים, כולל קלט של משתמשים, נתוני רשת וקבצים, כדי למנוע התקפות הזרקה ונקודות חולשה אחרות.
הקשחת אפשרויות ההידור
אפשר לחזק ספריות מקומיות שמשתמשות בפורמט ELF מפני מגוון נקודות חולשה על ידי הפעלת מנגנוני הגנה כמו הגנה על סטאק (Canary), העברה לקריאה בלבד (RELRO), מניעת ביצוע נתונים (NX) וקובצי הפעלה שאינם תלויים במיקום (PIE). לידיעתכם, כברירת מחדל, כל אמצעי ההגנה האלה מופעלים כבר באפשרויות הידור של Android NDK.
כדי לאמת את ההטמעה של מנגנוני האבטחה האלה בתוך קובץ בינארי, אפשר להשתמש בכלים כמו hardening-check או 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
מוודאים שספריות של צד שלישי לא חשופות לנקודות חולשה
כשבוחרים ספריות של צד שלישי, כדאי לתת עדיפות לשימוש בספריות שיש להן מוניטין בקהילת הפיתוח. מקורות מידע כמו Google Play SDK Index יכולים לעזור לכם לזהות ספריות מהימנות ומומלצות. חשוב לוודא שהספריות מעודכנות לגרסאות האחרונות ולחפש באופן יזום נקודות חולשה ידועות שקשורות אליהן, באמצעות משאבים כמו מסדי הנתונים של Exploit-DB. חיפוש באינטרנט באמצעות מילות מפתח כמו [library_name] vulnerability או [library_name] CVE עלול לחשוף מידע קריטי בנושא אבטחה.
משאבים
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-26 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 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)"]]
