אבטחת האפליקציות

רכיבים של אפליקציות

Android מספקת פלטפורמה וסביבה של אפליקציות בקוד פתוח למכשירים ניידים. ליבת מערכת ההפעלה מבוססת על ליבה של Linux. בדרך כלל, אפליקציות Android נכתבות בשפת התכנות Java ופועלות במכונה הווירטואלית Android Runtime‏ (ART). עם זאת, אפשר גם לכתוב אפליקציות בקוד מקורי. אפליקציות מותקנות מקובץ יחיד עם סיומת קובץ APK.

אבני הבניין העיקריות של אפליקציות ל-Android הן:

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

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

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

• Broadcast Receiver: BroadcastReceiver הוא אובייקט שנוצר כאשר מערכת ההפעלה או אפליקציה אחרת נותנות פקודה למנגנון IPC שנקרא Intent. אפליקציה יכולה לרשום מקלט להודעה על סוללה חלשה, למשל, ולשנות את ההתנהגות שלה על סמך המידע הזה.

מודל ההרשאות של Android: גישה לממשקי API מוגנים

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

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

ממשקי ה-API המוגנים האלה כוללים:

• פונקציות המצלמה
• נתוני מיקום (GPS)
• פונקציות Bluetooth
• פונקציות טלפוניה
• פונקציות של SMS/MMS
• חיבורי רשת/נתונים

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

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

בהגדרות המכשיר, המשתמשים יכולים לראות את ההרשאות של האפליקציות שהם התקינו בעבר. המשתמשים יכולים גם להשבית פונקציונליות מסוימת באופן גלובלי, למשל להשבית את ה-GPS, הרדיו או ה-Wi-Fi.

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

ההרשאות שמוגדרות כברירת מחדל במערכת מתוארות בכתובת https://developer.android.com/reference/android/Manifest.permission.html. אפליקציות יכולות להצהיר על הרשאות משלהם לשימוש באפליקציות אחרות. הרשאות כאלה לא מפורטות במיקום שלמעלה.

כשמגדירים הרשאה, המאפיין protectionLevel מאפשר למערכת לקבוע איך המשתמש יקבל הודעה על אפליקציות שדורשות את ההרשאה, או מי מורשה להחזיק בהרשאה. פרטים על יצירת הרשאות ספציפיות לאפליקציה ועל שימוש בהן מפורטים במאמר https://developer.android.com/guide/topics/security/security.html.

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

איך המשתמשים מבינים מהן אפליקציות צד שלישי

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

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

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

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

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

הרשאות בזמן התקנת האפליקציה – Google Translate	ההרשאות של אפליקציה מותקנת – Gmail

איור 1. הצגת ההרשאות של אפליקציות

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

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

ב-Android יש גם מנגנוני IPC חדשים:

• Binder: מנגנון קל משקל של קריאה לפרוצדורה מרוחקת (RPC) שמבוסס על יכולות, שנועד לספק ביצועים גבוהים בזמן ביצוע קריאות בתוך תהליך ובין תהליכים. Binder מיושם באמצעות מנהל Linux מותאם אישית. למידע נוסף: https://developer.android.com/reference/android/os/Binder.html.

• שירותים: שירותים (שצוינו למעלה) יכולים לספק ממשקים שאפשר לגשת אליהם ישירות באמצעות binder.

• כוונות: כוונה היא אובייקט הודעה פשוט שמייצג "כוונה" לבצע משהו. לדוגמה, אם האפליקציה רוצה להציג דף אינטרנט, היא מבטאת את 'כוונתה' להציג את כתובת ה-URL על ידי יצירת מופע Intent והעברתו למערכת. המערכת מאתרת קטע קוד אחר (במקרה הזה, הדפדפן) שיודע לטפל ב-Intent הזה, ומריצה אותו. אפשר גם להשתמש בכוונות כדי לשדר אירועים מעניינים (כמו התראה) ברחבי המערכת. למידע נוסף: https://developer.android.com/reference/android/content/Intent.html.

• ContentProviders: ContentProvider הוא מאגר נתונים שמספק גישה לנתונים במכשיר. הדוגמה הקלאסית היא ContentProvider שמשמשת לגישה לרשימת אנשי הקשר של המשתמש. אפליקציה יכולה לגשת לנתונים שאפליקציות אחרות חשפו באמצעות ContentProvider, וגם להגדיר ContentProviders משלה כדי לחשוף נתונים משלה. למידע נוסף: https://developer.android.com/reference/android/content/ContentProvider.html.

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

ממשקי API עם התמקדות בעלויות

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

• טלפוניה
• SMS/MMS
• רשת/נתונים
• חיוב על רכישות באפליקציות
• גישה ל-NFC

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

גישה לכרטיס ה-SIM

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

מידע אישי

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

איור 2. הגישה לנתוני משתמשים רגישים זמינה רק דרך ממשקי API מוגנים

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

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

התקני קלט של מידע אישי רגיש

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

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

מטא-נתונים של המכשיר

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

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

רשויות אישורים

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

כדי להוסיף רשות אישורים ציבורית חדשה לחבילת ברירת המחדל של Android, רשות האישור צריכה להשלים את תהליך ההכללה של רשות אישורים ב-Mozilla ולאחר מכן להגיש בקשה להוספת תכונה ל-Android ( https://code.google.com/p/android/issues/entry) כדי להוסיף את רשות האישור לחבילת ברירת המחדל של רשויות האישור ב-Android ב-Android Open Source Project‏ (AOSP).

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

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

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

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

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

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

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

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

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

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

ניהול זכויות דיגיטלי (DRM)

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

ה-framework של Android DRM מוטמע בשתי שכבות ארכיטקטוניות (ראו איור בהמשך):

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

• מנהל DRM בקוד מקורי, שמטמיע את מסגרת ה-DRM ומציג ממשק ל-plug-ins (סוכנים) של DRM לטיפול בניהול זכויות ובפענוח של סכמות DRM שונות

איור 3. הארכיטקטורה של DRM בפלטפורמת Android