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

فئة 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.

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

عمليات التحقّق من Lint في Android

عند إعلان الأذونات المخصصة، يمكنك استخدام عمليات فحص أداة Android Lint لمساعدتك في العثور على الأخطاء الكتابية والأخطاء المحتملة الأخرى في رمزك.

اصطلاحات التسمية

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

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

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

ومع ذلك، لا يتم أحيانًا تحديد هذه الأذونات من خلال علامة <permission> مقابلة في بيان حزمة APK على الجهاز. وفي هذه الحالة، يُطلق عليها اسم الأذونات غير المرتبطة. يمكن أن يحدث هذا الموقف لعدة أسباب، مثل:

  • قد يكون هناك عدم توافق بين التعديلات في البيان والرمز البرمجي الذي يتضمّن التحقّق من الأذونات.
  • قد لا يتم تضمين حِزمة APK التي تتضمّن الأذونات في الإصدار، أو قد يتم تضمين الإصدار الخطأ
  • قد يكون هناك خطأ إملائي في اسم الإذن في البيان أو في عملية التحقّق.

يمكن لتطبيق ضار تحديد إذن معزول ويحصل عليه. في حال حدوث ذلك، قد يتم اختراق التطبيقات المميّزة التي تثق بالإذن غير المتوفّر في التطبيق لحماية أحد المكوّنات.

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

ويمكن أن يؤدي ذلك أيضًا إلى خداع التطبيق المفوَّض لاعتقاد أنّ التطبيق الضار هو تطبيق مشروع، وبالتالي تحميل الملفات أو المحتوى.

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

تأكَّد من أنّ جميع الأذونات المخصّصة التي يستخدمها تطبيقك لحماية المكوّنات قد تم تحديدها أيضًا في البيان.

يستخدم التطبيق الإذنَين المخصّصَين my.app.provider.READ وmy.app.provider.WRITE لحماية إمكانية الوصول إلى موفّر المحتوى:

حجم كبير جدًا

<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 ويجب أن يفصح عنه على النحو التالي في بيانه:

حجم كبير جدًا

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

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

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

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

الخطر: حالة السباق

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

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

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

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

المراجع