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

אלמנטים של יישומים

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

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

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

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

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

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

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

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

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

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

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

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

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

בתוך הגדרות המכשיר, משתמשים יכולים לראות הרשאות עבור יישומים שהם התקינו בעבר. משתמשים יכולים גם לכבות פונקציונליות מסוימת בכל העולם, כאשר הם בוחרים, כגון השבתת 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.

כיצד משתמשים מבינים יישומי צד שלישי

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

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

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

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

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

הרשאות בהתקנת יישומים - Google Translate	הרשאות של יישום מותקן - Gmail

איור 1. הצגת הרשאות ליישומים

תקשורת בין-תהליכית

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

אנדרואיד מספקת גם מנגנוני IPC חדשים:

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

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

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

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

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

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

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

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

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

גישה לכרטיס SIM

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

מידע אישי

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

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

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

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

התקני קלט נתונים רגישים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניהול זכויות דיגיטליות

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

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

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

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

איור 3. ארכיטקטורה של ניהול זכויות דיגיטליות בפלטפורמת אנדרואיד