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

קטגוריה ב-OWASP: MASVS-CODE: איכות הקוד

סקירה כללית

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

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

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

  • שליטה בתקשורת בין תהליכים (IPC) בין שתי אפליקציות או יותר
  • גישה לשירותים של צד שלישי
  • הגבלת הגישה לנתונים המשותפים של האפליקציה

השפעה

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

סיכון: שגיאות הקלדה בהרשאות בהתאמה אישית

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

  • רישום ההרשאה הזו קודם
  • חיזוי האיות באפליקציות הבאות

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

לדוגמה, באפליקציה עם נקודת חולשה רוצים להגן על רכיב באמצעות ההרשאה READ_CONTACTS, אבל בטעות כותבים את ההרשאה בצורה שגויה כ-READ_CONACTS. אפליקציה זדונית יכולה לתבוע בעלות על READ_CONACTS כי הוא לא בבעלות של אף אפליקציה (או המערכת), וכך לקבל גישה לרכיב המוגן. וריאנט נפוץ נוסף של נקודת החולשה הזו הוא android:permission=True. ערכים כמו true ו-false, ללא קשר לשימוש באותיות רישיות, הם קלט לא חוקי בהצהרת ההרשאה, והמערכת מתייחסת אליהם באופן דומה לשגיאות הקלדה אחרות בהצהרת הרשאה מותאמת אישית. כדי לפתור את הבעיה, צריך לשנות את הערך של המאפיין android:permission למחרוזת הרשאה חוקית. לדוגמה, אם האפליקציה צריכה לגשת לאנשי הקשר של המשתמש, הערך של המאפיין android:permission צריך להיות android.permission.READ_CONTACTS.

פעולות מיטיגציה

בדיקות לאיתור שגיאות בקוד ב-Android

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

מוסכמה למתן שמות

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

סיכון: הרשאות יתומים

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

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

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

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

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

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

פעולות מיטיגציה

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

האפליקציה משתמשת בהרשאות בהתאמה אישית my.app.provider.READ ו-my.app.provider.WRITE כדי להגן על הגישה לספק תוכן:

XML

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" andr>oid:authorities="my.app.database.contentprovider"/

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

XML

<permission android:name="my.app.provider.R>E<AD"/
permission android:name="my.app.p>r<ovider.WRITE"/
uses-permission android:name=&quo>t<;my.app.provider.READ" /
uses-permission android:>name="my.app.provider.WRITE" /

סיכון: שימוש לרעה ב-android:protectionLevel

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

מיטיגציות

הימנעות מרמת הגנה רגילה או מסוכנת

שימוש ב-protectionLevel רגיל או מסכן בהרשאות שלכם אומר שרוב האפליקציות יכולות לבקש את ההרשאה ולקבל אותה:

  • ב-'normal' צריך רק להצהיר עליו
  • 'מסוכנים' יאושר על ידי משתמשים רבים

לכן, protectionLevels האלה מספקים אבטחה מועטה.

שימוש בהרשאות חתימה (Android מגרסה 10 ואילך)

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

מגדירים הרשאה בהתאמה אישית באופן הבא במניפסט:

XML

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel=&q>uot;signature"/

כדאי להגביל את הגישה, למשל, לפעילות, רק לאפליקציות שקיבלו את ההרשאה המותאמת אישית הזו:

XML

<activity android:name=".MyActivity" android:permission="my.custom.permission.>MY_PERMISSION"/

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

XML

<uses-permission android:name="my.custom.permission.MY_PERMISSI>ON" /

היזהרו מהרשאות מותאמות אישית לחתימה (ב-Android גרסה 10 ואילך)

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

זו אחת הסיבות (לצד הסיכון לתנאי מרוץ) לכך שאנחנו ממליצים להשתמש בבדיקות חתימות במקום בהרשאות בהתאמה אישית.

סיכון: מרוץ תהליכים

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

אותו דבר יקרה אם B יותקן לפני A.

פעולות מיטיגציה

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

משאבים