فئة 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 Lint
عند الإفصاح عن الأذونات المخصّصة، استخدِم عمليات التحقّق من الأخطاء في Android لمساعدتك في العثور على أخطاء إملائية وغيرها من الأخطاء المحتمَلة في الرمز البرمجي.
اصطلاح التسمية
استخدِم اصطلاح تسمية متّسقًا لجعل الأخطاء الإملائية أكثر وضوحًا. عليك التمعن في بيانات الأذونات المخصّصة في ملف بيان تطبيقك بحثًا عن الأخطاء الإملائية.
الخطر: الأذونات غير المرتبطة بتطبيق
تُستخدَم الأذونات لحماية موارد التطبيقات. هناك مكانان مختلفان يمكن للتطبيق فيهما الإفصاح عن الأذونات المطلوبة للوصول إلى موارده:
- AndroidManifest.xml: مُحدَّد مسبقًا في ملف AndroidManifest.xml (إذا لم يتم تحديده، يتم استخدام أذونات
<application>
)، مثل إذن الموفِّر وإذن المستلِم وإذن النشاط وإذن الخدمة - الرمز: مسجّل في رمز التشغيل، على سبيل المثال:
registerReceiver()
.
ومع ذلك، لا يتم أحيانًا تحديد هذه الأذونات من خلال علامة
<permission>
مقابلة في بيان حزمة APK على الجهاز. وفي هذه الحالة، يُطلق عليها اسم الأذونات غير المرتبطة. يمكن أن يحدث هذا الموقف لعدة
أسباب، مثل:
- قد يكون هناك عدم توافق بين التعديلات في البيان والرمز البرمجي الذي يتضمّن التحقّق من الأذونات.
- قد لا يتم تضمين حزمة APK التي تتضمّن الأذونات في الإصدار، أو قد يتم تضمين الإصدار الخاطئ.
- قد يكون هناك خطأ إملائي في اسم الإذن في البيان أو في عملية التحقّق.
يمكن لتطبيق ضار تحديد إذن غير متوفّر في أي تطبيق آخر والحصول عليه. في حال حدوث ذلك، قد يتم اختراق التطبيقات المميّزة التي تثق بالإذن غير المتوفّر في التطبيق لحماية أحد المكوّنات.
في الحالات التي يستخدم فيها التطبيق المفوَّض الإذن لحماية أي مكوّن أو حظره، قد يؤدي ذلك إلى منح التطبيق الضار إمكانية الوصول إلى هذا المكوّن. وتشمل الأمثلة بدء أنشطة محمية بإذن أو الوصول إلى مقدّم محتوى أو البث إلى جهاز استقبال بث محمي بالإذن المُهمَل.
ويمكن أن يؤدي ذلك أيضًا إلى خداع التطبيق المفوَّض لاعتقاده أنّ التطبيق الضار هو تطبيق مشروع، وبالتالي تحميل الملفات أو المحتوى.
إجراءات التخفيف
تأكَّد من أنّ جميع الأذونات المخصّصة التي يستخدمها تطبيقك لحماية المكوّنات قد تم تحديدها أيضًا في البيان.
يستخدم التطبيق الإذنَين المخصّصَين 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" android:authorities="my.app.database.contentprovider"/>
يحدِّد التطبيق أيضًا هذه الأذونات المخصّصة ويستخدمها، ما يمنع التطبيقات الضارّة الأخرى من إجراء ذلك:
Xml
<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />
الخطر: إساءة استخدام android:protectionLevel
تصف هذه السمة مستوى المخاطر المحتملة في الإذن، و تشير إلى الإجراءات التي يجب أن يتّبعها النظام عند اتخاذ قرار بشأن منح الإذن أم لا.
إجراءات التخفيف
تجنُّب مستوى الحماية "عادي" أو "خطير"
يعني استخدام protectionLevel
عادي أو خطير في أذوناتك أنّه يمكن لمعظم التطبيقات طلب الإذن والحصول عليه:
- لا يتطلّب الخيار "عادي" سوى الإفصاح عنه.
- سيوافق العديد من المستخدمين على أنّ المحتوى "خطير".
وبالتالي، لا توفّر هذه protectionLevels
سوى قدر ضئيل من الأمان.
استخدام أذونات التوقيع (الإصدار 10 من Android والإصدارات الأحدث)
استخدِم مستويات حماية التوقيعات كلما أمكن. من خلال استخدام هذه الميزة، يضمن المطوِّر أنّه لا يمكن للتطبيقات الأخرى التي تم توقيعها باستخدام الشهادة نفسها التي تم استخدامها لإنشاء الإذن الوصول إلى هذه الميزات المحمية. تأكَّد من استخدام شهادة توقيع مخصّصة (غير مُعاد استخدامها) واحفظها بأمان في ملف تخزين مفاتيح.
حدِّد إذنًا مخصّصًا على النحو التالي في البيان:
Xml
<permission
android:name="my.custom.permission.MY_PERMISSION"
android:protectionLevel="signature"/>
يمكنك حصر الوصول إلى نشاط معيّن، مثلاً، بالتطبيقات التي حصلت على هذا الإذن المخصّص فقط، وذلك على النحو التالي:
Xml
<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>
سيتم منح أي تطبيق آخر موقَّع باستخدام الشهادة نفسها المستخدَمة في التطبيق الذي أفصح عن
هذا الإذن المخصّص إذن الوصول إلى نشاط .MyActivity
ويجب أن يفصح عنه على النحو التالي في بيانه:
Xml
<uses-permission android:name="my.custom.permission.MY_PERMISSION" />
الحذر من الأذونات المخصّصة للتوقيع (في الإصدارات الأقدم من Android 10)
إذا كان تطبيقك يستهدف الإصدار 10 من نظام التشغيل Android أو الإصدارات الأقدم، عند إزالة أذونات تطبيقك المخصّصة
بسبب عمليات إلغاء التثبيت أو التحديثات، قد تكون هناك تطبيقات ضارة قادرة على
مواصلة استخدام هذه الأذونات المخصّصة وبالتالي تجاوز عمليات التحقّق. ويرجع ذلك إلى ثغرة أمنية في تصعيد الأذونات (CVE-2019-2200
) تم إصلاحها في الإصدار 10 من نظام التشغيل Android.
وهذا هو أحد الأسباب (إلى جانب خطر حدوث حالات تعارض) التي تجعلنا ننصح باستخدام فحص التوقيعات بدلاً من الأذونات المخصّصة.
الخطر: حالة السباق
إذا عرَّف تطبيق شرعي A
إذنًا مخصّصًا للتوقيع يستخدمه
تطبيقات X
أخرى ولكن تم إلغاء تثبيته لاحقًا، يمكن لتطبيق ضار B
تحديد هذا الإذن المخصّص نفسه باستخدام protectionLevel
مختلف، مثل
عادي. بهذه الطريقة، يحصل تطبيق B
على إذن الوصول إلى جميع المكوّنات المحمية باستخدام هذا الإذن المخصّص في تطبيقات X
بدون الحاجة إلى التوقيع باستخدام الشهادة نفسها المستخدَمة في التطبيق A
.
يحدث الشيء نفسه إذا تم تثبيت B
قبل A
.
إجراءات التخفيف
إذا أردت إتاحة مكوّن للتطبيقات التي تم توقيعها باستخدام التوقيع نفسه المستخدَم في التطبيق الموفّر، قد تتمكّن من تجنُّب تحديد أذونات مخصّصة لفرض قيود على الوصول إلى هذا المكوّن. في هذه الحالة، يمكنك استخدام عمليات التحقّق من التوقيعات. عندما يقدّم أحد تطبيقاتك طلبًا إلى أحد التطبيقات الأخرى، يمكن للتطبيق الثاني التحقّق من توقيع كلا التطبيقين باستخدام الشهادة نفسها قبل الامتثال للطلب.
المراجع
- تقليل طلبات الأذونات
- نظرة عامة على الأذونات
- وصف مستويات الحماية
- CustomPermissionTypo Android Lint
- كيفية استخدام أداة Android Lint
- ورقة بحثية تتضمّن شرحًا مفصّلاً لأذونات Android ونتائج مثيرة للاهتمام لاختبارات التداخل