مجوزهای سفارشی

دسته OWASP: MASVS-CODE: کیفیت کد

نمای کلی

خطرات مرتبط با مجوزهای سفارشی زمانی به وجود می‌آیند که تعریف مجوزهای سفارشی وجود نداشته باشد یا اشتباه املایی شود، یا زمانی که مشخصه android:protectionLevel مربوطه در Manifest سوء استفاده شود.

به عنوان مثال، این خطرات را می توان با ایجاد یک مجوز سفارشی با همین نام، اما توسط یک برنامه مخرب تعریف شده و با سطوح مختلف حفاظتی اعمال شده، مورد سوء استفاده قرار داد.

مجوزهای سفارشی برای فعال کردن اشتراک‌گذاری منابع و قابلیت‌ها با سایر برنامه‌ها طراحی شده‌اند. نمونه هایی از استفاده مشروع از مجوزهای سفارشی می تواند موارد زیر باشد:

  • کنترل ارتباطات بین فرآیندی (IPC) بین دو یا چند برنامه
  • دسترسی به خدمات شخص ثالث
  • محدود کردن دسترسی به داده های مشترک یک برنامه

تاثیر

تأثیر سوء استفاده از این آسیب‌پذیری این است که یک برنامه مخرب می‌تواند به منابعی که در ابتدا برای محافظت در نظر گرفته شده بود دسترسی پیدا کند. پیامدهای آسیب پذیری به منبع محافظت شده و مجوزهای مربوط به سرویس برنامه اصلی بستگی دارد.

ریسک: اشتباهات تایپی مجوز سفارشی

ممکن است یک مجوز سفارشی در Manifest اعلام شود، اما به دلیل یک اشتباه تایپی، از یک مجوز سفارشی متفاوت برای محافظت از اجزای Android صادر شده استفاده می شود. یک برنامه مخرب می‌تواند روی برنامه‌هایی که مجوز را اشتباه نوشته‌اند توسط یکی از موارد زیر استفاده کند:

  • ابتدا آن مجوز را ثبت کنید
  • پیش بینی املا در برنامه های بعدی

این می تواند به یک برنامه اجازه دسترسی غیرمجاز به منابع یا کنترل برنامه قربانی را بدهد.

برای مثال، یک برنامه آسیب‌پذیر می‌خواهد با استفاده از مجوز READ_CONTACTS از یک مؤلفه محافظت کند اما به‌طور تصادفی مجوز را به‌عنوان READ_CONACTS اشتباه می‌نویسد. یک برنامه مخرب می تواند READ_CONACTS ادعا کند زیرا متعلق به هیچ برنامه ای (یا سیستم) نیست و به مؤلفه محافظت شده دسترسی پیدا می کند. یکی دیگر از انواع رایج این آسیب پذیری android:permission=True است. مقادیری مانند true و false ، صرف نظر از حروف بزرگ، ورودی های نامعتبر برای اعلامیه مجوز هستند و مانند سایر اشتباهات تایپی اعلامیه مجوز سفارشی با آنها رفتار می شود. برای رفع این مشکل، مقدار ویژگی android:permission باید به یک رشته مجوز معتبر تغییر یابد. برای مثال، اگر برنامه نیاز به دسترسی به مخاطبین کاربر داشته باشد، مقدار ویژگی android:permission باید android.permission.READ_CONTACTS باشد.

اقدامات کاهشی

بررسی لینت اندروید

هنگام اعلام مجوزهای سفارشی، از بررسی لینت اندروید استفاده کنید تا به شما کمک کند تا اشتباهات تایپی و سایر خطاهای احتمالی را در کد خود پیدا کنید.

کنوانسیون نامگذاری

از یک قرارداد نامگذاری ثابت استفاده کنید تا اشتباهات تایپی بیشتر قابل توجه باشد. اعلان‌های مجوز سفارشی در Manifest برنامه‌تان را برای اشتباهات املایی به دقت بررسی کنید.

خطر: مجوزهای یتیم

مجوزها برای محافظت از منابع برنامه ها استفاده می شود. دو مکان مختلف وجود دارد که یک برنامه می تواند مجوزهای مورد نیاز برای دسترسی به منابع را اعلام کند:

با این حال، گاهی اوقات این مجوزها توسط یک برچسب <permission> مربوطه در مانیفست یک APK در دستگاه تعریف نمی شوند. در این مورد، آنها مجوزهای یتیم نامیده می شوند. این وضعیت ممکن است به دلایل مختلفی رخ دهد، مانند:

  • ممکن است بین به‌روزرسانی‌های Manifest و کد با بررسی مجوز، همگام‌سازی وجود نداشته باشد
  • ممکن است APK با مجوزها در ساخت گنجانده نشود یا نسخه اشتباهی گنجانده شود
  • نام مجوز در چک یا مانیفست ممکن است به اشتباه نوشته شود

یک برنامه مخرب می تواند یک مجوز یتیم را تعریف کند و آن را به دست آورد. اگر این اتفاق بیفتد، برنامه‌های ممتازی که به مجوز یتیم برای محافظت از یک مؤلفه اعتماد دارند، ممکن است به خطر بیفتند.

در مواردی که برنامه ممتاز از مجوز برای محافظت یا محدود کردن هر مؤلفه استفاده می‌کند، این می‌تواند به برنامه مخرب دسترسی به آن مؤلفه را بدهد. مثال‌ها شامل راه‌اندازی فعالیت‌هایی است که با مجوز محافظت می‌شوند، دسترسی به ارائه‌دهنده محتوا، یا پخش به یک گیرنده پخش که توسط مجوز یتیم محافظت می‌شود.

همچنین می‌تواند شرایطی را ایجاد کند که برنامه ممتاز فریب بخورد و تصور کند برنامه مخرب یک برنامه قانونی است و بنابراین فایل‌ها یا محتوا را بارگیری می‌کند.

اقدامات کاهشی

اطمینان حاصل کنید که همه مجوزهای سفارشی که برنامه شما برای محافظت از مؤلفه‌ها استفاده می‌کند، در Manifest شما نیز تعریف شده باشند.

این برنامه از مجوزهای سفارشی 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)

تا جایی که ممکن است از سطوح حفاظتی امضا استفاده کنید. استفاده از این قابلیت تضمین می‌کند که فقط سایر برنامه‌های امضا شده با گواهینامه مشابه برنامه‌ای که مجوز را ایجاد کرده است می‌توانند به این ویژگی‌های محافظت شده دسترسی داشته باشند. اطمینان حاصل کنید که از گواهی امضای اختصاصی (نه استفاده مجدد) استفاده می کنید و آن را به طور ایمن در فروشگاه کلید ذخیره کنید.

یک مجوز سفارشی را به صورت زیر در Manifest خود تعریف کنید:

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 دسترسی پیدا می کند و باید آن را به شرح زیر در Manifest خود اعلام کند:

Xml 

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

مراقب مجوزهای سفارشی امضا (Android < 10) باشید

اگر برنامه شما Android < 10 را هدف قرار می دهد، پس هر زمان که مجوزهای سفارشی برنامه شما به دلیل حذف نصب یا به روز رسانی حذف می شود، ممکن است برنامه های مخرب همچنان بتوانند از آن مجوزهای سفارشی استفاده کنند و در نتیجه بررسی ها را دور بزنند. این به دلیل یک آسیب‌پذیری افزایش امتیاز ( CVE-2019-2200 ) است که در اندروید 10 برطرف شده است.

این یکی از دلایلی است (همراه با خطر شرایط مسابقه) که چرا بررسی امضا بر روی مجوزهای سفارشی توصیه می شود.

خطر: شرایط مسابقه

اگر یک برنامه قانونی A یک مجوز سفارشی امضا را تعریف می کند که توسط سایر برنامه های X استفاده می شود اما متعاقباً حذف نصب می شود، یک برنامه مخرب B می تواند همان مجوز سفارشی را با یک protectionLevel متفاوت تعریف کند، به عنوان مثال عادی . به این ترتیب، B به تمام مؤلفه‌های محافظت شده توسط آن مجوز سفارشی در برنامه‌های X بدون نیاز به امضای گواهینامه مشابه با برنامه A دسترسی پیدا می‌کند.

همین اتفاق می افتد اگر B قبل از A نصب شود.

اقدامات کاهشی

اگر می‌خواهید یک مؤلفه را فقط برای برنامه‌هایی که با امضای مشابه برنامه ارائه‌دهنده امضا شده‌اند در دسترس قرار دهید، ممکن است بتوانید از تعریف مجوزهای سفارشی برای محدود کردن دسترسی به آن مؤلفه اجتناب کنید. در این شرایط می توانید از چک امضا استفاده کنید. وقتی یکی از برنامه‌های شما درخواستی برای یکی دیگر از برنامه‌های شما ارائه می‌کند، برنامه دوم می‌تواند تأیید کند که هر دو برنامه با یک گواهی امضا شده‌اند، قبل از انجام درخواست.

منابع