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

קטגוריה ב-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 עלול לחשוף מידע קריטי בנושא אבטחה.

משאבים