שימוש בקוד מקורי

קטגוריה של OWASP: MASVS-CODE: איכות הקוד

סקירה כללית

אפליקציות ל-Android יכולות לנצל קוד Native שנכתב בשפות כמו C ו-C++‎ לפונקציות ספציפיות. עם זאת, כשיישום משתמש ב-Java Native Interface ‏ (JNI) כדי ליצור אינטראקציה עם קוד ה-Native הזה, הוא עלול להיחשף לפגיעויות כמו גלישת חוצץ ובעיות אחרות שעשויות להיות בהטמעה של קוד ה-Native.

השפעה

למרות ההשפעות החיוביות מאוד כמו אופטימיזציה של הביצועים וערפול קוד (obfuscation), שימוש בקוד Native באפליקציות ל-Android עלול להשפיע לרעה על האבטחה. בשפות קוד Native כמו C/C++ אין תכונות של בטיחות זיכרון כמו ב-Java/Kotlin, ולכן הן חשופות לנקודות חולשה כמו עומסי יתר במאגר הנתונים הזמני, שגיאות use-after-free ובעיות אחרות של פגיעה בזיכרון – מה שמוביל לקריסות או להרצת קוד שרירותי. בנוסף, אם קיימת נקודת חולשה ברכיב של קוד Native, היא עלולה לסכן את כל האפליקציה, גם אם שאר הקוד נכתב בצורה מאובטחת ב-Java.

אמצעי צמצום סיכונים

הנחיות לפיתוח ולקידוד

  • הנחיות לכתיבת קוד מאובטח: בפרויקטים של C/C++‎, צריך לפעול בהתאם לתקנים המקובלים לכתיבת קוד מאובטח (למשל, CERT,‏ OWASP) כדי לצמצם את הסיכון לפגיעויות כמו גלישת חוצץ, גלישת מספרים שלמים ומתקפות של מחרוזות פורמט. מומלץ לתת עדיפות לספריות כמו Abseil, שמוכרות באיכות ובאבטחה שלהן. כשאפשר, כדאי להשתמש בשפות שמוגנות מפני שגיאות בזיכרון, כמו Rust, שמציעות ביצועים דומים ל-C/C++.
  • אימות קלט: צריך לאמת באופן קפדני את כל נתוני הקלט שמתקבלים ממקורות חיצוניים, כולל קלט של משתמשים, נתוני רשת וקבצים, כדי למנוע מתקפות החדרת קוד ונקודות חולשה אחרות.

הגברת האבטחה של אפשרויות ההידור

אפשר להפעיל מנגנוני הגנה כמו הגנה על מחסנית (Canary), העברה לקריאה בלבד (RELRO), מניעת הרצת נתונים (NX) וקבצים הפעלה בלתי תלויים במיקום (PIE), כדי להקשיח ספריות מקוריות שמשתמשות בפורמט ELF מפני מגוון פגיעויות. לשמחתנו, אפשרויות ההידור של 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 יכולים לעזור לכם לזהות ספריות מוערכות ומהימנות. חשוב לוודא שהספריות מעודכנות לגרסאות האחרונות, ולחפש באופן יזום פגיעויות ידועות שקשורות אליהן באמצעות מקורות מידע כמו מסדי הנתונים של Exploit-DB. חיפוש באינטרנט באמצעות מילות מפתח כמו [library_name] vulnerability או [library_name] CVE יכול לחשוף מידע אבטחה קריטי.

משאבים