רשימת משימות אבטחה

ל-Android יש תכונות אבטחה מובנות שמפחיתות באופן משמעותי את התדירות וההשפעה של בעיות אבטחה באפליקציות. המערכת מתוכננת כך שבדרך כלל אפשר לבנות את האפליקציות עם הרשאות ברירת המחדל של המערכת והקבצים, ולהימנע מהחלטות קשות לגבי אבטחה.

תכונות האבטחה העיקריות הבאות עוזרות לכם לפתח אפליקציות מאובטחות:

  • ארגז החול של אפליקציה ל-Android, שמבודד את נתוני האפליקציה ואת הרצת הקוד מאפליקציות אחרות.
  • מסגרת אפליקציה עם הטמעות חזקות של פונקציונליות אבטחה נפוצה, כמו קריפטוגרפיה, הרשאות ותקשורת מאובטחת בין תהליכים (IPC).
  • טכנולוגיות כמו address space layout randomization (ASLR),‏ no-execute (NX), ‏ ProPolice, ‏ safe_iop,‏ OpenBSD dlmalloc ו-calloc, ו-Linux mmap_min_addr עוזרות לצמצם את הסיכונים שקשורים לשגיאות נפוצות בניהול הזיכרון.
  • הרשאות שניתנות על ידי המשתמשים כדי להגביל את הגישה לתכונות המערכת ולנתוני המשתמשים.
  • הרשאות שהוגדרו על ידי האפליקציה כדי לשלוט בנתוני האפליקציה על בסיס כל אפליקציה.

חשוב להכיר את השיטות המומלצות לאבטחה ב-Android שמפורטות בדף הזה. הקפדה על השיטות האלה כהרגל כללי בכתיבת קוד עוזרת לכם להימנע מהחדרה לא מכוונת של בעיות אבטחה שמשפיעות לרעה על המשתמשים.

אימות

אימות הוא תנאי מוקדם להרבה פעולות אבטחה חשובות. כדי לשלוט בגישה לנכסים מוגנים כמו נתוני משתמשים, תכונות האפליקציה ומשאבים אחרים, צריך להוסיף אימות לאפליקציית Android.

כדי לשפר את חוויית האימות של המשתמשים, אפשר לשלב את האפליקציה עם Credential Manager. Credential Manager היא ספריית Android Jetpack שמאחדת את התמיכה ב-API ברוב שיטות האימות העיקריות, כולל מפתחות גישה, סיסמאות ופתרונות כניסה מאוחדים כמו כניסה באמצעות חשבון Google.

כדי לשפר עוד יותר את האבטחה של האפליקציה, כדאי להוסיף שיטות אימות ביומטרי כמו סריקות של טביעות אצבע או זיהוי פנים. אפליקציות שמתאימות להוספת אימות ביומטרי הן אפליקציות לניהול פיננסי, בריאות או זהויות.

מסגרת המילוי האוטומטי של Android יכולה לפשט את תהליך ההרשמה והכניסה, וכך להפחית את שיעורי השגיאות ואת התסכולים של המשתמשים. המילוי האוטומטי משולב עם מנהלי סיסמאות, ומאפשר למשתמשים לבחור סיסמאות מורכבות ואקראיות שאפשר לשמור ולאחזר בקלות ובאופן מאובטח.

שלמות האפליקציה

Play Integrity API עוזר לכם לוודא שהאינטראקציות והבקשות מהשרת מגיעות מהקוד הבינארי המקורי של האפליקציה שפועלת במכשיר מקורי עם Android. השימוש ב-Play Integrity API מאפשר לשרת העורפי של האפליקציה לזהות אינטראקציות שעלולות להיות מסוכנות או כאלה שמקורן בתרמית, למשל אינטראקציות מגרסאות של אפליקציות שעברו שינוי לא מורשה ומסביבות לא מהימנות, ולהגיב בהתאם כדי למנוע התקפות וניצול לרעה.

אחסון הנתונים

הבעיה הכי נפוצה שקשורה לאבטחה באפליקציה ב-Android היא האם אפליקציות אחרות יכולות לגשת לנתונים ששמרתם במכשיר. יש שלוש דרכים בסיסיות לשמירת נתונים במכשיר:

  • אחסון פנימי
  • אחסון חיצוני
  • ספקי תוכן

בקטעים הבאים מתוארות בעיות האבטחה שקשורות לכל אחת מהגישות.

אחסון פנימי

כברירת מחדל, רק האפליקציה יכולה לגשת לקבצים שאתם יוצרים באחסון הפנימי. מערכת Android מטמיעה את ההגנה הזו, והיא מספיקה לרוב האפליקציות.

מומלץ להימנע משימוש במצבי MODE_WORLD_WRITEABLE ו-MODE_WORLD_READABLE שהוצאו משימוש לקבצי IPC. הם לא מאפשרים להגביל את הגישה לנתונים לאפליקציות מסוימות, והם לא מספקים אפשרות לשלוט בפורמט הנתונים. אם רוצים לשתף את הנתונים עם תהליכים של אפליקציות אחרות, כדאי להשתמש בספק תוכן, שמציע הרשאות קריאה וכתיבה לאפליקציות אחרות ויכול להעניק הרשאות דינמיות על בסיס כל מקרה לגופו.

אחסון חיצוני

קבצים שנוצרו באחסון חיצוני, כמו כרטיסי SD, ניתנים לקריאה ולכתיבה באופן גלובלי. המשתמש יכול להסיר את האחסון החיצוני, וכל אפליקציה יכולה לשנות אותו. לכן, כדאי לאחסן באחסון חיצוני רק מידע לא רגיש.

צריך לבצע אימות של הקלט כשמטפלים בנתונים מאחסון חיצוני, כמו שצריך לעשות עם נתונים מכל מקור לא מהימן. אל תשמרו קבצים הפעלה או קבצי class באחסון חיצוני לפני טעינה דינמית. אם האפליקציה מאחזרת קבצים הפעלה מאחסון חיצוני, צריך לוודא שהקבצים חתומים ומאומתים קריפטוגרפית לפני הטעינה הדינמית.

ספקי תוכן

ספקי תוכן מציעים מנגנון אחסון מובנה שאפשר להגביל אותו לאפליקציה שלכם או לייצא אותו כדי לאפשר גישה לאפליקציות אחרות. אם לא מתכוונים לספק לאפליקציות אחרות גישה אל ContentProvider, צריך לסמן אותו כandroid:exported=false במניפסט של האפליקציה. אחרת, מגדירים את המאפיין android:exported לערך true כדי לאפשר לאפליקציות אחרות לגשת לנתונים המאוחסנים.

כשיוצרים ContentProvider שמיועד לייצוא לשימוש באפליקציות אחרות, אפשר לציין הרשאה אחת לקריאה ולכתיבה, או לציין הרשאות נפרדות לקריאה ולכתיבה. כדאי להגביל את ההרשאות רק לאלה שנדרשות לביצוע המשימה. חשוב לזכור שבדרך כלל קל יותר להוסיף הרשאות מאוחר יותר כדי לחשוף פונקציונליות חדשה, מאשר להסיר אותן ולהשפיע על משתמשים קיימים.

אם אתם משתמשים בספק תוכן כדי לשתף נתונים רק בין האפליקציות שלכם, מומלץ להשתמש במאפיין android:protectionLevel עם ההגדרה signature. הרשאות חתימה לא דורשות אישור מהמשתמש, ולכן הן מספקות חוויית משתמש טובה יותר ומאפשרות גישה מבוקרת יותר לנתונים של ספק התוכן, כשהאפליקציות שמקבלות גישה לנתונים חתומות עם אותו מפתח.

ספקי תוכן יכולים גם לספק גישה מפורטת יותר על ידי הצהרה על המאפיין android:grantUriPermissions ושימוש בדגלים FLAG_GRANT_READ_URI_PERMISSION ו-FLAG_GRANT_WRITE_URI_PERMISSION באובייקט Intent שמפעיל את הרכיב. אפשר להגביל עוד יותר את היקף ההרשאות האלה באמצעות הרכיב <grant-uri-permission>.

כשניגשים ל-ContentProvider, מומלץ להשתמש בשיטות שאילתה עם פרמטרים כמו query,‏ update ו-delete() כדי למנוע הזרקת SQL ממקורות לא מהימנים. שימו לב: שימוש בשיטות עם פרמטרים לא מספיק אם הארגומנט selection נוצר על ידי שרשור של נתוני משתמשים לפני שליחתו לשיטה.

אל תחשבו שאתם מוגנים בגלל הרשאת הכתיבה. הרשאת הכתיבה מאפשרת הצהרות SQL שמאפשרות לאשר חלק מהנתונים באמצעות תנאי WHERE יצירתיים וניתוח התוצאות. לדוגמה, תוקף יכול לבדוק אם מספר טלפון ספציפי מופיע ביומן שיחות על ידי שינוי שורה רק אם מספר הטלפון הזה כבר קיים. אם לנתונים של ספק התוכן יש מבנה צפוי, יכול להיות שהרשאת הכתיבה שווה למתן הרשאת קריאה והרשאת כתיבה.

הרשאות

מכיוון שב-Android האפליקציות מבודדות זו מזו בארגז חול, הן צריכות לשתף משאבים ונתונים באופן מפורש. הם עושים זאת על ידי הצהרה על ההרשאות שהם צריכים ליכולות נוספות שלא מסופקות על ידי ארגז החול הבסיסי, כולל גישה לתכונות המכשיר כמו המצלמה.

בקשות הרשאה

צריך לצמצם את מספר ההרשאות שהאפליקציה מבקשת. הגבלת הגישה להרשאות רגישות מפחיתה את הסיכון לשימוש לרעה בהרשאות האלה שלא במתכוון, משפרת את אימוץ האפליקציה על ידי המשתמשים והופכת את האפליקציה לפחות פגיעה בפני תוקפים. באופן כללי, אם הרשאה מסוימת לא נדרשת כדי שהאפליקציה תפעל, אל תבקשו אותה. במדריך הזה מוסבר איך להעריך אם צריך להצהיר על הרשאות באפליקציה.

אם אפשר, כדאי לתכנן את האפליקציה כך שלא תדרוש הרשאות. לדוגמה, במקום לבקש גישה לפרטי המכשיר כדי ליצור מזהה ייחודי, אפשר ליצור UUID לאפליקציה. (מידע נוסף זמין בקטע על נתוני משתמשים). או, במקום להשתמש באחסון חיצוני (שדורש הרשאה), לאחסן את הנתונים באחסון הפנימי.

בנוסף לבקשת הרשאות, האפליקציה יכולה להשתמש ברכיב <permission> כדי להגן על IPC שרגיש לאבטחה וחשוף לאפליקציות אחרות, כמו ContentProvider. באופן כללי, מומלץ להשתמש באמצעי בקרת גישה אחרים ולא בהרשאות שמאושרות על ידי המשתמשים, כי הרשאות עלולות לבלבל את המשתמשים. לדוגמה, כדאי להשתמש ברמת ההגנה על החתימה בהרשאות לתקשורת IPC בין אפליקציות שסופקו על ידי מפתח יחיד.

לא לחשוף נתונים שמוגנים על ידי הרשאות. המצב הזה מתרחש כשהאפליקציה חושפת נתונים באמצעות IPC שזמינים רק בגלל שהאפליקציה קיבלה הרשאה לגשת לנתונים האלה. יכול להיות שללקוחות של ממשק ה-IPC של האפליקציה אין את אותה הרשאת גישה לנתונים. פרטים נוספים על התדירות וההשפעות הפוטנציאליות של הבעיה הזו מופיעים במאמר המחקר Permission Re-Delegation: Attacks and Defenses שפורסם ב-USENIX.

הגדרות של הרשאות

הגדרת קבוצת ההרשאות הקטנה ביותר שעונה על דרישות האבטחה שלכם. יצירת הרשאה חדשה היא פעולה יחסית לא נפוצה ברוב האפליקציות, כי ההרשאות שמוגדרות על ידי המערכת מכסות הרבה מצבים. במקרים המתאימים, מבצעים בדיקות גישה באמצעות הרשאות קיימות.

אם אתם צריכים הרשאה חדשה, כדאי לבדוק אם אפשר לבצע את המשימה עם רמת הגנה על החתימה. הרשאות החתימה שקופות למשתמש ומאפשרות גישה רק לאפליקציות שנחתמו על ידי אותו מפתח כמו האפליקציה שמבצעת את בדיקת ההרשאות.

אם עדיין נדרשת הרשאה חדשה, צריך להצהיר עליה בקובץ מניפסט של אפליקציה באמצעות הרכיב <permission>. אפליקציות שמשתמשות בהרשאה החדשה יכולות להפנות אליה על ידי הוספת רכיב <uses-permission> לקובצי המניפסט שלהן. אפשר גם להוסיף הרשאות באופן דינמי באמצעות השיטה addPermission().

אם יוצרים הרשאה עם רמת ההגנה המסוכנת, יש כמה מורכבויות שצריך לקחת בחשבון:

  • להרשאה צריך להיות מחרוזת שמבטאת באופן תמציתי למשתמש את החלטת האבטחה שהוא נדרש לקבל.
  • מחרוזת ההרשאות צריכה להיות מותאמת לשוק המקומי בשפות רבות ושונות.
  • יכול להיות שהמשתמשים יבחרו שלא להתקין אפליקציה כי הרשאה מסוימת לא ברורה או נתפסת כמסוכנת.
  • יכול להיות שאפליקציות יבקשו את ההרשאה אם האפליקציה שיצרה את ההרשאה לא מותקנת.

כל אחת מהן יוצרת אתגר משמעותי לא טכני עבורך כמפתח, וגם מבלבלת את המשתמשים. לכן אנחנו לא ממליצים להשתמש ברמת ההרשאה המסוכנת.

Networking

עסקאות ברשת הן מסוכנות מבחינת אבטחה, כי הן כוללות העברת נתונים שעלולים להיות פרטיים של המשתמש. אנשים מודעים יותר ויותר לבעיות שקשורות לפרטיות במכשיר נייד, במיוחד כשהמכשיר מבצע טרנזקציות ברשת, ולכן חשוב מאוד שהאפליקציה שלכם תיישם את כל השיטות המומלצות כדי לשמור על אבטחת הנתונים של המשתמש בכל עת.

רשתות IP

התקשורת ברשת ב-Android לא שונה באופן משמעותי מסביבות Linux אחרות. הדבר החשוב ביותר הוא לוודא שנעשה שימוש בפרוטוקולים מתאימים למידע אישי רגיש, כמו HttpsURLConnection לתעבורת אינטרנט מאובטחת. מומלץ להשתמש ב-HTTPS במקום ב-HTTP בכל מקום שבו השרת תומך ב-HTTPS, כי מכשירים ניידים מתחברים לעיתים קרובות לרשתות לא מאובטחות, כמו נקודות חמות של Wi-Fi ציבורי.

אפשר להטמיע בקלות תקשורת מאומתת ומוצפנת ברמת השקע באמצעות המחלקה SSLSocket. בהתחשב בתדירות שבה מכשירי Android מתחברים לרשתות אלחוטיות לא מאובטחות באמצעות Wi-Fi, מומלץ מאוד להשתמש ברשתות מאובטחות בכל האפליקציות שמתקשרות ברשת.

חלק מהאפליקציות משתמשות ביציאות רשת של מארח מקומי לטיפול ב-IPC רגיש. אל תשתמשו בגישה הזו, כי אפליקציות אחרות במכשיר יכולות לגשת לממשקים האלה. במקום זאת, אפשר להשתמש במנגנון Android IPC שבו אפשר לבצע אימות, למשל באמצעות Service. קישור לכתובת ה-IP הלא ספציפית INADDR_ANY גרוע יותר משימוש ב-loopback, כי הוא מאפשר לאפליקציה לקבל בקשות מכל כתובת IP.

חשוב לוודא שלא מסתמכים על נתונים שהורדו מ-HTTP או מפרוטוקולים לא מאובטחים אחרים. זה כולל אימות של קלט ב-WebView וכל תגובה לכוונות שהונפקו מול HTTP.

רשתות טלפוניה

פרוטוקול שירות הודעות קצרות (SMS) תוכנן בעיקר לתקשורת בין משתמשים, והוא לא מתאים לאפליקציות שרוצות להעביר נתונים. בגלל המגבלות של SMS, מומלץ להשתמש בהעברת הודעות בענן ב-Firebase ‏ (FCM) וברשת IP כדי לשלוח הודעות נתונים משרת אינטרנט לאפליקציה במכשיר של משתמש.

חשוב לדעת ש-SMS לא מוצפן ולא מאומת בצורה חזקה ברשת או במכשיר. בפרט, כל מי שמקבל SMS צריך לצפות לכך שמשתמש זדוני עלול לשלוח את ה-SMS לאפליקציה שלכם. אל תסתמכו על נתוני SMS לא מאומתים כדי לבצע פקודות רגישות. בנוסף, חשוב לדעת שרשתות יכולות לזייף או ליירט הודעות SMS. במכשיר עם Android, הודעות SMS מועברות כ-broadcast intents, כך שאפליקציות אחרות עם הרשאה READ_SMS יכולות לקרוא או לתפוס אותן.

אימות קלט

אימות לא מספיק של קלט הוא אחת מבעיות האבטחה הנפוצות ביותר שמשפיעות על אפליקציות, לא משנה באיזו פלטפורמה הן פועלות. ל-Android יש אמצעי נגד ברמת הפלטפורמה שמצמצמים את החשיפה של אפליקציות לבעיות באימות הקלט, ואנחנו ממליצים להשתמש בתכונות האלה ככל האפשר. בנוסף, מומלץ להשתמש בשפות בטוחות מבחינת טיפוס כדי להפחית את הסיכוי לבעיות באימות הקלט.

אם אתם משתמשים בקוד מקורי, כל נתון שנקרא מקבצים, מתקבל דרך הרשת או מתקבל מ-IPC, עלול לגרום לבעיה אבטחתית. הבעיות הנפוצות ביותר הן גלישת חוצץ, שימוש אחרי שחרור ושגיאות של הבדל של אחד. מערכת Android מספקת מספר טכנולוגיות, כמו ASLR ו-DEP (מניעת הפעלת נתונים), שמפחיתות את הפגיעות של השגיאות האלה, אבל הן לא פותרות את הבעיה הבסיסית. כדי למנוע את נקודות החולשה האלה, צריך לטפל בזהירות במצביעים ולנהל את המאגרים.

שפות דינמיות שמבוססות על מחרוזות, כמו JavaScript ו-SQL, גם הן חשופות לבעיות באימות הקלט בגלל תווי escape והחדרת סקריפטים.

אם אתם משתמשים בנתונים בשאילתות שנשלחות למסד נתונים של SQL או לספק תוכן, יכול להיות שזו בעיה שקשורה להזרקת SQL. ההגנה הכי טובה היא שימוש בשאילתות עם פרמטרים, כמו שמוסבר בקטע על ספקי תוכן. הגבלת ההרשאות לקריאה בלבד או לכתיבה בלבד יכולה גם להקטין את הסיכון לנזק שקשור להזרקת SQL.

אם אתם לא יכולים להשתמש בתכונות האבטחה שמוסברות בקטע הזה, הקפידו להשתמש בפורמטים של נתונים מובְנים ולוודא שהנתונים תואמים לפורמט הצפוי. אסטרטגיה יעילה יכולה להיות חסימה של תווים ספציפיים או החלפה של תווים, אבל בפועל השיטות האלה עלולות לגרום לשגיאות, ולכן מומלץ להימנע מהן ככל האפשר.

נתוני המשתמש

הגישה הכי טובה לאבטחת נתוני משתמשים היא לצמצם את השימוש בממשקי API שניגשים למידע רגיש או אישי. אם יש לכם גישה לנתוני משתמשים, כדאי להימנע מאחסון או מהעברה שלהם אם אפשר. כדאי לבדוק אם אפשר להטמיע את הלוגיקה של האפליקציה באמצעות גיבוב או באמצעות צורה לא הפיכה של הנתונים. לדוגמה, יכול להיות שהאפליקציה שלכם משתמשת בגיבוב של כתובת אימייל כמפתח ראשי כדי להימנע מהעברה או מאחסון של כתובת האימייל. כך מצמצמים את הסיכוי לחשיפת נתונים בטעות, וגם את הסיכוי שתוקפים ינסו לנצל את האפליקציה.

בכל פעם שנדרשת גישה לנתונים פרטיים, צריך לאמת את המשתמש ולהשתמש בשיטות אימות מודרניות כמו מפתחות גישה והמרכז לניהול פרטי כניסה. אם האפליקציה שלכם צריכה לגשת למידע אישי, חשוב לזכור שייתכן שבחלק מהמדינות תצטרכו לספק מדיניות פרטיות שמסבירה איך אתם משתמשים בנתונים האלה ומאחסנים אותם. כדי לפשט את תהליך ההתאמה לתקנות, מומלץ לפעול לפי השיטה המומלצת לאבטחה של צמצום הגישה לנתוני משתמשים.

בנוסף, כדאי לבדוק אם האפליקציה עלולה לחשוף בטעות פרטים אישיים לצדדים אחרים, כמו רכיבי צד שלישי לפרסום או שירותי צד שלישי שבהם נעשה שימוש באפליקציה. אם אתם לא יודעים למה רכיב או שירות מסוימים דורשים מידע אישי, אל תספקו אותו. באופן כללי, צמצום הגישה של האפליקציה למידע אישי מצמצם את הסיכוי לבעיות בתחום הזה.

אם האפליקציה שלכם דורשת גישה למידע אישי רגיש, כדאי לבדוק אם אתם צריכים להעביר אותו לשרת או אם אתם יכולים להפעיל את הפעולה בלקוח. כדאי להריץ קוד שמשתמש במידע אישי רגיש בצד הלקוח כדי להימנע מהעברת נתוני משתמשים. בנוסף, חשוב לוודא שלא חושפים בטעות נתוני משתמשים לאפליקציות אחרות במכשיר באמצעות IPC עם הרשאות מוגזמות, קבצים עם הרשאת כתיבה לכל העולם או שקעי רשת. הרשאות IPC רחבות מדי הן מקרה מיוחד של דליפת נתונים שמוגנים באמצעות הרשאות, כפי שמוסבר בקטע בקשות הרשאה.

אם נדרש מזהה ייחודי גלובלי (GUID), צריך ליצור מספר גדול וייחודי ולאחסן אותו. אל תשתמשו במזהים של טלפונים, כמו מספר הטלפון או IMEI, שיכולים להיות משויכים למידע אישי. הנושא הזה מוסבר בפירוט בדף בנושא שיטות מומלצות ליצירת מזהים ייחודיים.

חשוב להיזהר כשכותבים ליומני רישום במכשיר. ב-Android, היומנים הם משאב משותף וזמינים לאפליקציה עם ההרשאה READ_LOGS. למרות שנתוני יומן הטלפון הם זמניים ונמחקים בהפעלה מחדש, רישום לא הולם של פרטי משתמש עלול לגרום לדליפת נתוני משתמשים לאפליקציות אחרות. בנוסף לכך, חשוב לא לרשום פרטים אישיים מזהים (PII) ביומן, ולהגביל את השימוש ביומן באפליקציות לייצור. כדי להטמיע את זה בקלות, אפשר להשתמש בדגלי ניפוי באגים ובמחלקות מותאמות אישית עם רמות רישום ביומן שקל להגדיר.Log

תצוגת האתר

השימוש הלא תקין ב-WebView עלול לגרום לבעיות נפוצות באבטחת אתרים, כמו פרצת אבטחה XSS‏ (cross-site scripting) (הזרקת JavaScript), כי הוא צורך תוכן אינטרנט שיכול לכלול HTML ו-JavaScript. ‫Android כולל מספר מנגנונים לצמצום היקף הבעיות הפוטנציאליות האלה על ידי הגבלת היכולת של WebView לפונקציונליות המינימלית שנדרשת על ידי האפליקציה.

אם האפליקציה שלכם לא משתמשת ישירות ב-JavaScript בתוך WebView, אל תפעילו את setJavaScriptEnabled. חלק מקוד לדוגמה משתמש בשיטה הזו. אם אתם משתמשים מחדש בקוד לדוגמה שמשתמש בשיטה הזו באפליקציית ייצור, צריך להסיר את הפעלת ה-method הזו אם היא לא נדרשת. כברירת מחדל, WebView לא מריץ JavaScript, ולכן אי אפשר לבצע cross-site scripting.

צריך להשתמש ב-addJavaScriptInterface() בזהירות רבה, כי היא מאפשרת ל-JavaScript להפעיל פעולות שבדרך כלל שמורות לאפליקציות ל-Android. אם משתמשים בו, צריך לחשוף את addJavaScriptInterface() רק לדפי אינטרנט שכל הקלט מהם מהימן. אם מותר קלט לא מהימן, יכול להיות ש-JavaScript לא מהימן יוכל להפעיל שיטות של Android באפליקציה שלכם. באופן כללי, מומלץ לחשוף את addJavaScriptInterface() רק ל-JavaScript שכלול ב-APK של האפליקציה.

אם האפליקציה שלכם ניגשת למידע אישי רגיש באמצעות WebView, כדאי להשתמש בשיטה clearCache() כדי למחוק קבצים שמאוחסנים באופן מקומי. אפשר גם להשתמש בכותרות בצד השרת, כמו no-store, כדי לציין שאפליקציה לא צריכה לשמור במטמון תוכן מסוים.

במכשירים שמותקנות בהם פלטפורמות ישנות יותר מ-Android 4.4‏ (API ברמה 19), נעשה שימוש בגרסה של webkit שיש בה מספר בעיות אבטחה. כפתרון עקיף, אם האפליקציה שלכם פועלת במכשירים האלה, היא צריכה לוודא שאובייקטים של WebView מציגים רק תוכן מהימן. כדי לוודא שהאפליקציה לא חשופה לפגיעויות פוטנציאליות ב-SSL, צריך להשתמש באובייקט האבטחה Provider שניתן לעדכון, כמו שמתואר במאמר עדכון ספק האבטחה כדי להגן מפני ניצול לרעה של SSL. אם האפליקציה שלכם צריכה להציג תוכן מהאינטרנט הפתוח, כדאי לספק רכיב משלכם לעיבוד התוכן כדי שתוכלו לעדכן אותו בתיקוני האבטחה האחרונים.

בקשות לפרטי כניסה

בקשות לפרטי כניסה הן וקטור לתקיפה. ריכזנו כאן כמה טיפים שיעזרו לכם להפוך את בקשות האישורים באפליקציות ל-Android למאובטחות יותר.

מזעור החשיפה של פרטי הכניסה

  • הימנעות מבקשות מיותרות של פרטי כניסה כדי להקשות על התקפות פישינג ולצמצם את הסיכוי שהן יצליחו, מומלץ לצמצם את התדירות שבה המערכת מבקשת מהמשתמשים את פרטי הכניסה שלהם. במקום זאת, צריך להשתמש בטוקן הרשאה ולרענן אותו. בקשו רק את הכמות המינימלית של פרטי האישורים שנדרשים לאימות ולאישור.
  • שמירת פרטי הכניסה באופן מאובטח. אפשר להשתמש בCredential Manager כדי להפעיל אימות ללא סיסמה באמצעות מפתחות גישה, או כדי להטמיע כניסה מאוחדת באמצעות סכימות כמו 'כניסה באמצעות חשבון Google'. אם אתם חייבים להשתמש באימות סיסמה מסורתי, אל תשמרו את מזהי המשתמשים והסיסמאות במכשיר. במקום זאת, צריך לבצע אימות ראשוני באמצעות שם המשתמש והסיסמה שהמשתמש סיפק, ואז להשתמש באסימון הרשאה לטווח קצר שספציפי לשירות.
  • הגבלת היקף ההרשאות. אל תבקשו הרשאות נרחבות למשימה שנדרש עבורה היקף מצומצם יותר.
  • הגבלת אסימוני גישה. מומלץ להשתמש בפעולות ובקריאות ל-API של אסימונים לטווח קצר.
  • הגבלת שיעורי האימות. בקשות חוזרות ונשנות לאימות או להרשאה יכולות להעיד על מתקפת כוח ברוטלי. חשוב להגביל את התדירות הזו לתדירות סבירה, ועדיין לאפשר חוויית שימוש פונקציונלית וידידותית באפליקציה.

שימוש באימות מאובטח

  • הטמעה של מפתחות גישה. הפעלה של מפתחות גישה כתחליף מאובטח יותר ונוח יותר לשימוש לסיסמאות.
  • הוספת נתונים ביומטריים. להציע אפשרות להשתמש באימות ביומטרי, כמו טביעת אצבע או זיהוי פנים, כדי להוסיף אבטחה.
  • שימוש בספקי זהויות מאוחדים. Credential Manager תומך בספקי אימות מאוחדים כמו כניסה באמצעות חשבון Google.
  • הצפנת התקשורת: צריך להשתמש ב-HTTPS ובטכנולוגיות דומות כדי לוודא שהנתונים שהאפליקציה שולחת ברשת מוגנים.

שימוש בשיטות לניהול מאובטח של החשבון

  • מתחברים לשירותים שאפשר לגשת אליהם מכמה אפליקציות באמצעות AccountManager. משתמשים במחלקה AccountManager כדי להפעיל שירות מבוסס-ענן, ולא מאחסנים סיסמאות במכשיר.
  • אחרי שמשתמשים ב-AccountManager כדי לאחזר Account, צריך להשתמש ב-CREATOR לפני שמזינים פרטי כניסה, כדי שלא להעביר פרטי כניסה בטעות לאפליקציה הלא נכונה.
  • אם פרטי הכניסה משמשים רק אפליקציות שאתם יוצרים, אתם יכולים לאמת את האפליקציה שניגשת אל AccountManager באמצעות checkSignatures. לחלופין, אם רק אפליקציה אחת משתמשת בהרשאה, אפשר להשתמש בKeyStore לאחסון.

בדקו היטב

  • חשוב לוודא שהקוד עדכני. כדי להגן על עצמכם מפני הפרצות האחרונות, חשוב לעדכן את קוד המקור, כולל ספריות ויחסי תלות של צד שלישי.
  • מעקב אחר פעילות חשודה. חיפוש שימוש לרעה פוטנציאלי, כמו דפוסים של שימוש לרעה בהרשאות.
  • בודקים את הקוד. מומלץ לבצע בדיקות אבטחה באופן קבוע בקוד הבסיס כדי לחפש בעיות פוטנציאליות בבקשות לאישורים.

ניהול מפתחות API

מפתחות API הם רכיב קריטי בהרבה אפליקציות ל-Android, והם מאפשרים לאפליקציות לגשת לשירותים חיצוניים ולבצע פונקציות חיוניות כמו התחברות לשירותי מיפוי, אימות ושירותי מזג אוויר. עם זאת, חשיפה של המפתחות הרגישים האלה עלולה להוביל להשלכות חמורות, כולל פרצות אבטחה, גישה לא מורשית והפסדים כספיים. כדי למנוע תרחישים כאלה, מפתחים צריכים להטמיע אסטרטגיות מאובטחות לטיפול במפתחות API לאורך תהליך הפיתוח.

כדי להגן על שירותים מפני שימוש לרעה, צריך להגן על מפתחות ה-API בקפידה. כדי לאבטח חיבור בין האפליקציה לבין שירות שמשתמש במפתח API, צריך לאבטח את הגישה ל-API. כשמבצעים קומפילציה של האפליקציה, וקוד המקור שלה כולל מפתחות API, יכול להיות שתוקף יבצע דה-קומפילציה של האפליקציה וימצא את המשאבים האלה.

הקטע הזה מיועד לשתי קבוצות של מפתחי Android: מפתחים שעובדים עם צוותי תשתית על צינור אספקה רציף, ומפתחים שמפיצים אפליקציות עצמאיות בחנות Play. בקטע הזה מפורטות שיטות מומלצות לטיפול במפתחות API, כדי שהאפליקציה תוכל לתקשר עם שירותים בצורה מאובטחת.

יצירה ואחסון

מפתחים צריכים להתייחס לאחסון של מפתחות API כאל רכיב קריטי בהגנה על נתונים ובשמירה על פרטיות המשתמשים, באמצעות גישה של הגנה נרחבת.

אחסון מפתחות חזק

כדי להשיג אבטחה אופטימלית בניהול המפתחות, מומלץ להשתמש ב-Android Keystore ולהצפין את המפתחות המאוחסנים באמצעות כלי חזק כמו Tink Java.

החרגה של בקרת מקור

אסור לשמור מפתחות API במאגר המקורות של הקוד. הוספת מפתחות API לקוד מקור עלולה לחשוף את המפתחות למאגרים ציבוריים, לדוגמאות קוד משותפות ולקבצים ששותפו בטעות. במקום זאת, אפשר להשתמש בתוספים של Gradle כמו secrets-gradle-plugin כדי לעבוד עם מפתחות API בפרויקט.

מפתחות ספציפיים לסביבה

אם אפשר, כדאי להשתמש במפתחות API נפרדים לסביבות פיתוח, בדיקה וייצור. שימוש במפתחות ספציפיים לסביבה מאפשר לבודד כל סביבה, להקטין את הסיכון לחשיפת נתונים בסביבת הייצור ולבטל מפתחות שנפרצו בלי להשפיע על סביבת הייצור.

שימוש ובקרת גישה

שיטות מאובטחות לשימוש במפתחות API חיוניות להגנה על ה-API ועל המשתמשים. כך מכינים את המפתחות לאבטחה אופטימלית:

  • יצירת מפתחות ייחודיים לכל אפליקציה: מומלץ להשתמש במפתחות API נפרדים לכל אפליקציה כדי לזהות ולבודד גישה שנפרצה.
  • הטמעת הגבלות על כתובות IP: אם אפשר, כדאי להגביל את השימוש במפתח API לכתובות IP או לטווחים ספציפיים.
  • הגבלת השימוש במפתחות של אפליקציות לנייד: אפשר להגביל את השימוש במפתחות API לאפליקציות ספציפיות לנייד על ידי צרור שלהם עם המפתח או על ידי שימוש באישורים של אפליקציות.
  • רישום ביומן ומעקב אחרי פעילות חשודה: כדאי להטמיע מנגנונים לרישום ביומן ולמעקב אחרי השימוש בממשקי API כדי לזהות פעילות חשודה ולמנוע ניצול לרעה.

הערה: השירות צריך לספק תכונות להגבלת מפתחות לחבילה או לפלטפורמה מסוימת. לדוגמה, Google Maps API מגביל את הגישה למפתח לפי שם החבילה ומפתח החתימה.

פרוטוקול OAuth 2.0 מספק מסגרת להרשאת גישה למשאבים. היא מגדירה תקנים לאופן האינטראקציה בין לקוחות ושרתים, ומאפשרת הרשאה מאובטחת. אתם יכולים להשתמש ב-OAuth 2.0 כדי להגביל את השימוש במפתח API ללקוחות ספציפיים, ולהגדיר את היקף הגישה כך שלכל מפתח API תהיה רק רמת הגישה המינימלית שנדרשת למטרה שלשמה הוא נועד.

רוטציית מפתחות ותוקף המפתח

כדי להפחית את הסיכון לגישה לא מורשית דרך נקודות חולשה לא ידועות ב-API, חשוב להחליף את מפתחות ה-API באופן קבוע. תקן ISO 27001 מגדיר מסגרת תאימות לגבי התדירות שבה צריך לבצע רוטציית מפתחות. ברוב המקרים, רוטציית מפתחות של 90 ימים עד 6 חודשים תספיק. הטמעה של מערכת ניהול מפתחות חזקה יכולה לעזור לכם לייעל את התהליכים האלה, ולשפר את היעילות של צורכי רוטציית המפתחות והתפוגה שלכם.

המלצות כלליות

  • שימוש ב-SSL/HTTPS: תמיד צריך להשתמש בתקשורת HTTPS כדי להצפין את בקשות ה-API.
  • הצמדת אישורים: כדי להוסיף עוד שכבת אבטחה, אפשר להטמיע הצמדת אישורים כדי לבדוק אילו אישורים נחשבים לתקפים.
  • אימות וניקוי של קלט משתמשים: חשוב לאמת ולנקות את קלט המשתמשים כדי למנוע מתקפות הזרקה שעלולות לחשוף מפתחות API.
  • פועלים לפי השיטות המומלצות לאבטחה: מיישמים שיטות מומלצות כלליות לאבטחה בתהליך הפיתוח, כולל טכניקות של קידוד מאובטח, בדיקות קוד וסריקות של נקודות חולשה.
  • להתעדכן: חשוב להתעדכן באיומי האבטחה האחרונים ובשיטות המומלצות לניהול מפתחות API.
  • ערכות SDK עדכניות: חשוב לוודא שערכות ה-SDK והספריות שלכם מעודכנות לגרסה האחרונה.

הצפנה

בנוסף לבידוד הנתונים, לתמיכה בהצפנה מלאה של מערכת הקבצים ולמתן ערוצי תקשורת מאובטחים, מערכת Android מספקת מגוון רחב של אלגוריתמים להגנה על הנתונים באמצעות קריפטוגרפיה.

צריך לדעת אילו ספקי אבטחה של Java Cryptography Architecture‏ (JCA) נמצאים בשימוש בתוכנה. כדאי לנסות להשתמש ברמה הגבוהה ביותר של הטמעה של מסגרת קיימת שיכולה לתמוך בתרחיש לדוגמה שלכם. אם רלוונטי, משתמשים בספקים ש-Google מספקת לפי הסדר ש-Google מציינת.

אם אתם צריכים לאחזר קובץ בצורה מאובטחת ממיקום רשת ידוע, יכול להיות ש-URI פשוט של HTTPS יספיק ולא תצטרכו ידע בקריפטוגרפיה. אם אתם צריכים מנהרה מאובטחת, כדאי להשתמש ב-HttpsURLConnection או ב-SSLSocket במקום לכתוב פרוטוקול משלכם. אם אתם משתמשים ב-SSLSocket, חשוב לדעת שהוא לא מבצע אימות של שם המארח. אזהרות לגבי שימוש ישיר ב-SSLSocket

אם אתם מגלים שאתם צריכים להטמיע פרוטוקול משלכם, אל תטמיעו אלגוריתמים קריפטוגרפיים משלכם. שימוש באלגוריתמים קריפטוגרפיים קיימים, כמו ההטמעות של AES ו-RSA שמופיעות במחלקה Cipher. בנוסף, כדאי לפעול לפי השיטות המומלצות הבאות:

  • שימוש ב-AES של 256 ביט למטרות מסחריות. (אם האפשרות הזו לא זמינה, צריך להשתמש ב-AES של 128 ביט).
  • משתמשים בגדלים של מפתחות ציבוריים של 224 או 256 ביט לקריפטוגרפיה של עקומות אליפטיות (EC).
  • איך יודעים מתי להשתמש במצבי בלוקים של CBC,‏ CTR או GCM.
  • הימנעו משימוש חוזר ב-IV/counter במצב CTR. חשוב לוודא שהם אקראיים מבחינה קריפטוגרפית.
  • כשמשתמשים בהצפנה, צריך להטמיע שלמות באמצעות מצב CBC או CTR עם אחת מהפונקציות הבאות:
    • HMAC-SHA1
    • HMAC-SHA-256
    • HMAC-SHA-512
    • מצב GCM

כדי לאתחל מפתחות קריפטוגרפיים שנוצרו על ידי KeyGenerator, צריך להשתמש במחולל מספרים אקראיים מאובטח, SecureRandom. שימוש במפתח שלא נוצר באמצעות מחולל מספרים אקראיים מאובטח מחליש באופן משמעותי את חוזק האלגוריתם, ועשוי לאפשר מתקפות אופליין.

אם אתם צריכים לאחסן מפתח לשימוש חוזר, השתמשו במנגנון כמו KeyStore, שמספק אחסון לטווח ארוך ואחזור של מפתחות קריפטוגרפיים.

תקשורת בין תהליכים (IPC)

חלק מהאפליקציות מנסות להטמיע IPC באמצעות טכניקות Linux מסורתיות, כמו שקעי רשת וקבצים משותפים. עם זאת, אנחנו ממליצים להשתמש במקום זאת בפונקציונליות של מערכת Android ל-IPC, כמו Intent, ‏ Binder או Messenger עם Service ו-BroadcastReceiver. מנגנוני ה-IPC של Android מאפשרים לאמת את הזהות של האפליקציה שמתחברת ל-IPC ולהגדיר מדיניות אבטחה לכל מנגנון IPC.

הרבה מרכיבי אבטחה משותפים למנגנוני IPC. אם מנגנון ה-IPC לא מיועד לשימוש באפליקציות אחרות, צריך להגדיר את המאפיין android:exported לערך false ברכיב המניפסט של הרכיב, למשל ברכיב <service>. האפשרות הזו שימושית לאפליקציות שמורכבות מכמה תהליכים באותו UID, או אם בשלב מאוחר בפיתוח מחליטים שלא רוצים לחשוף פונקציונליות כ-IPC, אבל לא רוצים לכתוב מחדש את הקוד.

אם ה-IPC שלכם נגיש לאפליקציות אחרות, אתם יכולים להחיל מדיניות אבטחה באמצעות הרכיב <permission>. אם ה-IPC הוא בין אפליקציות שלכם שחתומות באותו מפתח, צריך להשתמש בהרשאה signature-level ב-android:protectionLevel.

כוונות

במקרה של פעילויות ומקלטי שידורים, כוונות הן המנגנון המועדף לתקשורת בין תהליכים (IPC) אסינכרונית ב-Android. בהתאם לדרישות האפליקציה, יכול להיות שתשתמשו ב-sendBroadcast, ב-sendOrderedBroadcast או ב-intent מפורש לרכיב ספציפי באפליקציה. מטעמי אבטחה, מומלץ להשתמש ב-explicit intents.

שימו לב: הנמען יכול לצרוך שידורים מסודרים, ולכן יכול להיות שהם לא יועברו לכל האפליקציות. אם אתם שולחים Intent שצריך להימסר למקבל ספציפי, אתם צריכים להשתמש באובייקט Intent מפורש שמצהיר על המקבל לפי שם.

שולחי Intent יכולים לוודא שלנמען יש הרשאה על ידי ציון הרשאה שאינה null בהפעלת method. רק אפליקציות עם ההרשאה הזו מקבלות את הכוונה. אם נתונים ב-broadcast intent עשויים להיות רגישים, כדאי להחיל הרשאה כדי לוודא שאפליקציות זדוניות לא יוכלו להירשם לקבלת ההודעות האלה ללא הרשאות מתאימות. במקרים כאלה, אפשר גם להפעיל את המקלט ישירות, במקום לשלוח שידור.

שירותים

ספרייה Service משמשת לעיתים קרובות כדי לספק פונקציונליות לשימוש באפליקציות אחרות. לכל מחלקת שירות חייבת להיות הצהרת <service> תואמת בקובץ המניפסט שלה.

כברירת מחדל, השירותים לא מיוצאים ולא ניתן להפעיל אותם על ידי אף אפליקציה אחרת. עם זאת, אם מוסיפים מסנני כוונות להצהרת השירות, הוא מיוצא כברירת מחדל. מומלץ להצהיר במפורש על מאפיין android:exported כדי לוודא שהוא מתנהג כמו שרוצים. אפשר גם להגן על שירותים באמצעות המאפיין android:permission. כדי שאפליקציות אחרות יוכלו להפעיל את השירות, לעצור אותו או לקשר אותו, הן צריכות להצהיר על רכיב <uses-permission> תואם במניפסט שלהן.

שירות יכול להגן על שיחות IPC פרטניות שמתבצעות אליו באמצעות הרשאות. כדי לעשות זאת, צריך לקרוא ל-checkCallingPermission() לפני שמבצעים את ההטמעה של השיחה. מומלץ להשתמש בהצהרות הרשאות במניפסט, כי יש פחות סיכוי לפספס משהו כשמשתמשים בהן.

ממשקי Binder ו-Messenger

השימוש ב-Binder או ב-Messenger הוא המנגנון המועדף ל-IPC בסגנון RPC ב-Android. הם מספקים ממשקים מוגדרים היטב שמאפשרים אימות הדדי של נקודות הקצה, אם נדרש.

מומלץ לעצב את הממשקים של האפליקציה כך שלא יהיה צורך בבדיקות הרשאות ספציפיות לממשק. אובייקטים מסוג Binder ו-Messenger לא מוצהרים במניפסט של האפליקציה, ולכן אי אפשר להחיל עליהם הרשאות הצהרתיות באופן ישיר. בדרך כלל הן מקבלות בירושה את ההרשאות שהוצהרו במניפסט של האפליקציה עבור Service או Activity, שבהן הן מיושמות. אם אתם יוצרים ממשק שנדרשים בו אימות או אמצעי בקרה לגישה, אתם צריכים להוסיף את אמצעי הבקרה האלה באופן מפורש כקוד בממשק Binder או Messenger.

אם אתם מספקים ממשק שדורש אמצעי בקרת גישה, אתם יכולים להשתמש ב-checkCallingPermission() כדי לוודא שלמתקשר יש את ההרשאה הנדרשת. זה חשוב במיוחד לפני שאתם ניגשים לשירות בשם המתקשר, כי הזהות של האפליקציה שלכם מועברת לממשקים אחרים. אם אתם מפעילים ממשק שסופק על ידי Service, יכול להיות שההפעלה של bindService() תיכשל אם אין לכם הרשאה לגשת לשירות הנתון. אם אתם צריכים לאפשר לתהליך חיצוני ליצור אינטראקציה עם האפליקציה שלכם, אבל אין לו את ההרשאות הנדרשות לכך, אתם יכולים להשתמש בשיטה clearCallingIdentity(). השיטה הזו מבצעת את השיחה לממשק של האפליקציה כאילו האפליקציה עצמה מבצעת את השיחה, ולא המתקשר החיצוני. אפשר לשחזר את הרשאות המתקשר מאוחר יותר באמצעות השיטה restoreCallingIdentity().

מידע נוסף על ביצוע IPC עם שירות זמין במאמר Bound Services.

מקלטי שידורים

‫BroadcastReceiver מטפל בבקשות אסינכרוניות שמגיעות מ-Intent.

כברירת מחדל, רכיבי ה-Receiver מיוצאים וכל אפליקציה אחרת יכולה להפעיל אותם. אם רכיב ה-BroadcastReceiver מיועד לשימוש באפליקציות אחרות, כדאי להחיל הרשאות אבטחה על רכיבי ה-Receiver באמצעות רכיב <receiver> במניפסט האפליקציה. כך נמנע מאפליקציות ללא הרשאות מתאימות לשלוח Intent אל BroadcastReceiver.

אבטחה עם קוד שנטען באופן דינמי

אנחנו ממליצים מאוד לא לטעון קוד מחוץ לחבילת ה-APK של האפליקציה. הפעולה הזו מגדילה באופן משמעותי את הסיכוי לפריצה לאפליקציה בגלל הזרקת קוד או שינוי קוד. בנוסף, היא מוסיפה מורכבות לניהול הגרסאות ולבדיקת האפליקציות, ויכול להיות שהיא תמנע את האפשרות לאמת את ההתנהגות של אפליקציה, ולכן יכול להיות שהיא תהיה אסורה בסביבות מסוימות.

אם האפליקציה שלכם טוענת קוד באופן דינמי, הדבר הכי חשוב לזכור הוא שהקוד שנטען באופן דינמי פועל עם אותן הרשאות אבטחה כמו קובץ ה-APK של האפליקציה. המשתמש מקבל החלטה להתקין את האפליקציה על סמך הזהות שלכם, והוא מצפה שתספקו כל קוד שמופעל באפליקציה, כולל קוד שנטען באופן דינמי.

הרבה אפליקציות מנסות לטעון קוד ממיקומים לא מאובטחים, למשל הורדה מהרשת באמצעות פרוטוקולים לא מוצפנים או ממיקומים עם הרשאות כתיבה לכל העולם, כמו אחסון חיצוני. המיקומים האלה יכולים לאפשר למישהו ברשת לשנות את התוכן בזמן ההעברה או באפליקציה אחרת במכשיר של המשתמש, כדי לשנות את התוכן במכשיר. לעומת זאת, אי אפשר לשנות מודולים שנכללים ישירות בקובץ ה-APK על ידי אפליקציות אחרות. זה נכון גם אם הקוד הוא ספריית Native או מחלקה שנטענת באמצעות DexClassLoader.

אבטחה במכונה וירטואלית

‫Dalvik היא מכונה וירטואלית (VM) של זמן ריצה ב-Android. ‫Dalvik נוצרה במיוחד ל-Android, אבל הרבה מהחששות לגבי קוד מאובטח במכונות וירטואליות אחרות רלוונטיים גם ל-Android. באופן כללי, אין צורך לדאוג לגבי בעיות אבטחה שקשורות למכונה הווירטואלית. האפליקציה פועלת בסביבת ארגז חול מאובטחת, כך שתהליכים אחרים במערכת לא יכולים לגשת לקוד או לנתונים הפרטיים שלכם.

אם אתם רוצים לקבל מידע נוסף על אבטחת מכונות וירטואליות, כדאי לעיין בחומרים קיימים בנושא. שני מקורות מידע פופולריים במיוחד הם:

המאמר הזה מתמקד באזורים שספציפיים ל-Android או שונים מסביבות אחרות של מכונות וירטואליות. למפתחים שיש להם ניסיון בתכנות מכונות וירטואליות בסביבות אחרות, יש שתי בעיות כלליות שקשורות לכתיבת אפליקציות ל-Android:

  • מכונות וירטואליות מסוימות, כמו JVM או .NET runtime, פועלות כגבול אבטחה, ומבודדות את הקוד מהיכולות של מערכת ההפעלה הבסיסית. ב-Android, המכונה הווירטואלית של Dalvik לא מהווה גבול אבטחה – ארגז החול של האפליקציה מיושם ברמת מערכת ההפעלה, ולכן Dalvik יכולה לפעול עם קוד Native באותה אפליקציה ללא מגבלות אבטחה.
  • בגלל נפח האחסון המוגבל במכשירים ניידים, מפתחים בדרך כלל רוצים ליצור אפליקציות מודולריות ולהשתמש בטעינה דינמית של מחלקות. כשעושים את זה, צריך לקחת בחשבון גם את המקור שממנו מאחזרים את לוגיקת האפליקציה וגם את המקום שבו מאחסנים אותה באופן מקומי. אל תשתמשו בטעינה דינמית של מחלקות ממקורות שלא אומתו, כמו מקורות לא מאובטחים ברשת או אחסון חיצוני, כי יכול להיות שהקוד הזה ישונה כך שיכלול התנהגות זדונית.

אבטחה בקוד Native

באופן כללי, מומלץ להשתמש ב-Android SDK לפיתוח אפליקציות, ולא להשתמש בקוד Native עם Android NDK. אפליקציות שנבנו באמצעות קוד Native הן מורכבות יותר, פחות ניידות ויש סיכוי גבוה יותר שהן יכללו שגיאות נפוצות של פגיעה בזיכרון, כמו buffer overflows.

מערכת Android מבוססת על ליבת Linux, ולכן כדאי להכיר את השיטות המומלצות לאבטחת פיתוח ב-Linux, במיוחד אם אתם משתמשים בקוד נייטיב. שיטות לאבטחת Linux חורגות מהיקף המסמך הזה, אבל אחד המקורות הפופולריים ביותר הוא Secure Programming HOWTO - Creating Secure Software.

הבדל חשוב בין Android לבין רוב סביבות Linux הוא ארגז החול של האפליקציה. ב-Android, כל האפליקציות רצות בארגז החול של האפליקציה, כולל אלה שנכתבו באמצעות קוד Native. דרך טובה לחשוב על זה, למפתחים שמכירים את Linux, היא לדעת שלכל אפליקציה מוקצה מזהה משתמש (UID) ייחודי עם הרשאות מוגבלות מאוד. הנושא הזה מוסבר בפירוט בסקירה כללית בנושא אבטחה ב-Android, וכדאי להכיר את הרשאות האפליקציה גם אם אתם משתמשים בקוד מקורי.