קטגוריה ב-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
עלול לחשוף מידע קריטי בנושא אבטחה.
משאבים
- CWE-111: שימוש ישיר ב-JNI לא בטוח
- Exploit database
- בדיקת קבצים בינאריים לתכונות של הקשחת אבטחה
- בדיקת הגדרות האבטחה של קבצים בינאריים באמצעות pwntools
- הקשחת אבטחה של קבצים בינאריים ב-Linux
- הקשחת קבצים בינאריים של ELF באמצעות Relocation Read-Only (RELRO)
- מנגנוני הגנה בינאריים של OWASP
- תקני קידוד של SEI CERT
- מדריך למפתחים של OWASP
- Google Play SDK Index
- Android NDK
- מבוא ל-Rust ב-Android
- Abseil (ספריות נפוצות של C++)
- המקשר אוכף את PIE