שיטות מומלצות לאבטחת אפליקציות

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

סקר קוד

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

• כדי להבטיח כיסוי, חשוב לפעול לפי הנחיות אבטחה מקיפות כשעורכים בדיקות. כדאי להשתמש בתקנים פנימיים או חיצוניים רלוונטיים כדי לוודא שהביקורות עקביות ומלאות.
• מריצים כלי לבדיקת קוד, כמו Android Studio linter, על כל קוד האפליקציה באמצעות Android SDK ומתקנים את כל הבעיות שמזוהות.
• ניתוח קוד Native באמצעות כלי אוטומטי שיכול לזהות בעיות בניהול הזיכרון, כמו גלישת חוצץ ושגיאות של אחד יותר מדי או אחד פחות מדי.
• מערכת ה-build של Android תומכת בהרבה כלים לניקוי נתונים של LLVM, כמו AddressSanitizer ו-UndefinedBehaviorSanitizer, שאפשר להשתמש בהם לניתוח בזמן ריצה של בעיות שקשורות לזיכרון. בנוסף ל-fuzzing, שנתמך ב-Android באמצעות libFuzzer, אפשר להשתמש ב-sanitizers כדי לחשוף מקרים חריגים שדורשים בדיקה נוספת.
• מומלץ שמעריך אבטחה מנוסה יבדוק קוד עם סיכון גבוה יותר, כמו קוד קריפטו, קוד לעיבוד תשלומים וקוד לעיבוד מידע אישי.

בדיקות אוטומטיות

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

• כדאי להריץ את הגרסה העדכנית של CTS באופן קבוע לאורך תהליך הפיתוח כדי לזהות בעיות בשלב מוקדם ולקצר את הזמן שנדרש לתיקון. ‫Android משתמש ב-CTS כחלק מהאינטגרציה הרציפה בתהליך build האוטומטי שלנו, שמתבצע מספר פעמים ביום.
• אוטומציה של בדיקות אבטחה של ממשקים, כולל בדיקות עם קלט לא תקין (בדיקות fuzzing). מערכת ה-build של Android תומכת ב-libFuzzer לכתיבת בדיקות fuzz.

בדיקת נקודות חולשה

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

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

אפליקציות שעלולות להזיק

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

מידע נוסף על PHA ועל האופן שבו Google נלחמת בהן בחנות Play זמין במסמכי התיעוד למפתחים של Google Play Protect.

התקנה והרשאות של אפליקציות

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

• אל תעניקו הרשאות או זכויות מיותרות לאפליקציות שהותקנו מראש. חשוב לבדוק היטב אפליקציות עם הרשאות מערכת, כי יכולות להיות להן הרשאות רגישות מאוד.
• חשוב לוודא שכל ההרשאות המבוקשות רלוונטיות ונחוצות לפונקציונליות של האפליקציה הספציפית.
• מוודאים שיש גילוי נאות למשתמשים לגבי כל האפליקציות שמותקנות מראש ומשתמשות בהרשאה INSTALL_PACKAGES.
• מוודאים שהמפתח מחויב חוזית לא להתקין אפליקציות כמזהה משתמש 0.
• הערכת ההרשאות שמוצהרות במניפסט של כל האפליקציות שיוגדרו להתקנה דרך הרשת של המפתח.
• חשוב לוודא שהמפתח מחויב חוזית לסרוק את כל כתובות ה-URL להורדה של אפליקציות לעדכון אוטומטי ולאפליקציות להתקנה באמצעות Google Safe Browsing API לפני שהאפליקציות מוגשות למכשיר.

חתימה על אפליקציות

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

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

בידוד אפליקציות ותהליכים

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

בידוד של תהליכי הבסיס

תהליכי Root הם היעד הכי נפוץ של מתקפות להסלמת הרשאות. צמצום מספר תהליכי ה-Root מפחית את הסיכון להסלמת הרשאות.

• מוודאים שהמכשירים מריצים את הקוד המינימלי הנדרש כמשתמש root. כשאפשר, כדאי להשתמש בתהליך Android רגיל ולא בתהליך בסיסי. אם תהליך מסוים צריך לפעול כ-root במכשיר, צריך לתעד את התהליך בבקשת תכונה ב-AOSP כדי שניתן יהיה לבדוק אותו באופן ציבורי.
• במקרים שבהם הדבר אפשרי, צריך לבודד את קוד הבסיס מנתונים לא מהימנים ולגשת אליו באמצעות תקשורת בין תהליכים (IPC). לדוגמה, אפשר לצמצם את הפונקציונליות של root לשירות קטן שאפשר לגשת אליו דרך Binder, ולחשוף את השירות עם הרשאת חתימה לאפליקציה עם הרשאות נמוכות או ללא הרשאות, כדי לטפל בתנועת נתונים ברשת.
• תהליכי הבסיס לא יכולים להאזין לשקע רשת.
• תהליכי הבסיס לא יכולים לכלול סביבת זמן ריצה לשימוש כללי, כמו Java VM.

בידוד אפליקציות מערכת

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

• מוודאים שהמכשירים מריצים את הקוד המינימלי הנדרש כמערכת. אם אפשר, משתמשים בתהליך Android עם UID משלו במקום לעשות שימוש חוזר ב-UID של המערכת.
• במקרים שבהם הדבר אפשרי, קוד המערכת צריך להיות מבודד מנתונים לא מהימנים, וצריך לחשוף IPC רק לתהליכים מהימנים אחרים.
• תהליכי המערכת לא יכולים להאזין לשקע רשת. זו דרישה של CTS.

בידוד תהליכים

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

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