الأذونات المخصّصة

فئة 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 lint لمساعدتك في العثور على الأخطاء الإملائية والأخطاء المحتمَلة الأخرى في الرمز.

نمط التسمية

استخدِم نمط تسمية متسقًا لجعل الأخطاء الإملائية أكثر وضوحًا. تحقَّق بعناية من تعريفات الأذونات المخصّصة في ملف بيان تطبيقك بحثًا عن الأخطاء الإملائية.

الخطر: الأذونات غير المرتبطة

تُستخدَم الأذونات لحماية موارد التطبيقات. هناك مكانان مختلفان يمكن للتطبيق فيهما تعريف الأذونات المطلوبة للوصول إلى الموارد:

ومع ذلك، في بعض الأحيان، لا يتم تعريف هذه الأذونات من خلال علامة <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 هذه مستوى أمان منخفضًا.

استخدام أذونات التوقيع (Android 10 والإصدارات الأحدث)

استخدِم مستويات حماية التوقيع كلما أمكن ذلك. يضمن استخدام هذه الإمكانية أنّه لا يمكن للتطبيقات الأخرى الموقَّعة بالشهادة نفسها التي تم توقيع التطبيق الذي أنشأ الإذن بها الوصول إلى هذه الميزات المحمية. تأكَّد من استخدام شهادة توقيع مخصّصة (غير معاد استخدامها) وخزِّنها بأمان في ملف تخزين مفاتيح.

عرِّف إذنًا مخصّصًا على النحو التالي في ملف البيان:

‫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)

إذا كان تطبيقك يستهدف Android أقل من 10، ففي أي وقت تتم فيه إزالة الأذونات المخصّصة لتطبيقك بسبب عمليات إلغاء التثبيت أو التحديثات، قد تتمكّن التطبيقات الضارة من مواصلة استخدام هذه الأذونات المخصّصة وبالتالي تجاوز عمليات التحقّق. يرجع ذلك إلى ثغرة أمنية لتصعيد الامتيازات (CVE-2019-2200) تم إصلاحها في Android 10.

هذا أحد الأسباب (بالإضافة إلى خطر حالات التزامن) التي تجعل عمليات التحقّق من التوقيعات مُفضّلة على الأذونات المخصّصة.

الخطر: حالة التزامن

إذا عرَّف تطبيق مشروع A إذنًا مخصّصًا للتوقيع تستخدمه تطبيقات X أخرى ولكن تم إلغاء تثبيته لاحقًا، يمكن لتطبيق ضار B تعريف هذا الإذن المخصّص نفسه باستخدام protectionLevel مختلف، مثل عادي. بهذه الطريقة، يمكن للتطبيق B الوصول إلى جميع المكوّنات المحمية بهذا الإذن المخصّص في تطبيقات X بدون الحاجة إلى توقيعه بالشهادة نفسها التي تم توقيع التطبيق A بها.

يحدث الأمر نفسه إذا تم تثبيت التطبيق B قبل التطبيق A.

إجراءات التخفيف

إذا أردت إتاحة مكوّن للتطبيقات الموقَّعة بالتوقيع نفسه الذي تم توقيع التطبيق الذي يوفّر المكوّن به فقط، قد تتمكّن من تجنُّب تعريف الأذونات المخصّصة لحظر الوصول إلى هذا المكوّن. في هذه الحالة، يمكنك استخدام عمليات التحقّق من التوقيعات. عندما يقدّم أحد تطبيقاتك طلبًا لتطبيق آخر، يمكن للتطبيق الثاني التحقّق من أنّ كلا التطبيقَين موقَّعان بالشهادة نفسها قبل الامتثال للطلب.

الموارد