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

קטגוריה ב-OWASP: MASVS-PLATFORM: Platform Interaction

סקירה כללית

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

רמות ההרשאות ב-Android מציינות את הסיכון הפוטנציאלי שמשויך להרשאה:

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

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

  • הרכיב לא משויך לאף android:permission ב-Manifest.
  • הרכיב מבצע משימה רגישה שיש לה הרשאה שהמשתמש כבר אישר.
  • הרכיב מיוצא.
  • הרכיב לא מבצע בדיקות הרשאה ידניות (ברמת המניפסט או ברמת הקוד).

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

השפעה

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

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

דרישה להרשאות לביצוע משימות רגישות

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

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

XML

<manifest ...>
    <uses-permission android:name="android.permission.READ_CONTACTS" />

    <application ...>
        <service android:name=".MyExportService"
                 android:exported="true"
                 android:permission="android.permission.READ_CONTACTS" />

        </application>
</manifest>

Kotlin

class MyExportService : Service() {

    private val binder = MyExportBinder()

    override fun onBind(intent: Intent): IBinder? {
        // Enforce calling app has the required permission
        enforceCallingPermission(Manifest.permission.READ_CONTACTS, "Calling app doesn't have READ_CONTACTS permission.")
        // Permission is enforced, proceed with export logic
        return binder
    }

    // Inner class for your Binder implementation
    private inner class MyExportBinder : Binder() {
        // Permission is enforced, proceed with export logic
    }
}

Java

public class MyExportService extends Service {

    @Override
    public IBinder onBind(Intent intent) {
        // Enforce calling app has the required permission
        enforceCallingPermission(Manifest.permission.READ_CONTACTS, "Calling app doesn't have READ_CONTACTS permission.");

        return binder;

    }

    // Inner class for your Binder implementation
    private class MyExportBinder extends Binder {
        // Permission is enforced, proceed with export logic

    }
}

לא מייצאים את הרכיב

הימנעו מייצוא רכיבים שיש להם גישה למשאבים רגישים, אלא אם יש צורך חיוני בכך. כדי לעשות זאת, צריך להגדיר את android:exported בקובץ Manifest כ-false עבור הרכיב. החל מרמת API 31 ואילך, המאפיין הזה מוגדר כברירת מחדל כ-false.

XML

<activity
    android:name=".MyActivity"
    android:exported="false"/>

החלת הרשאות מבוססות-חתימה

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

XML

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp">
    <permission android:name="my_custom_permission_name"
                android:protectionLevel="signature" />

נקודות קצה למשימות בודדות

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

משאבים