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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• שירותים: שירותים יכולים לספק ממשקי משתמש שנגישים ישירות באמצעות binder. תיאור מפורט יותר זמין במאמר בנושא רכיבים של אפליקציות

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

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

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

ממשקי API שרגישים לעלויות

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

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

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

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

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

פרטים אישיים

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

איור 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 ‏(AOSP).

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

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

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

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

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

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

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

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

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

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

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

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

מסגרת ה-DRM של Android מיושמת בשתי שכבות ארכיטקטוניות (ראו איור 3):

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

• מנהל DRM של קוד Native, שמטמיע את framework ה-DRM וחושף ממשק לפלאגינים של DRM (סוכנים) לטיפול בניהול זכויות ובפענוח של תוכניות DRM שונות

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