دسترسی‌پذیری برای کاربران ضروری است؛ خطر از اعطای بی‌دلیل دسترسی و سوءاستفاده از آن ایجاد می‌شود.
بدافزار همیشه لازم نیست رمزنگاری پیام را بشکند. اگر به داده‌ای که دستگاه برای نمایش یا ورود پردازش می‌کند دسترسی پیدا کند، ممکن است محتوا را پیش از رمزنگاری یا پس از رمزگشایی ببیند. سوءاستفاده از دسترسی‌پذیری و پنجره‌های پوششی دو نمونه‌اند، اما سازوکار آن‌ها یکی نیست.
همچنین هر برنامهٔ دارای Accessibility یا پنجرهٔ شناور بدافزار نیست. صفحه‌خوان‌ها و ابزارهای کمکی برای بسیاری از کاربران ضروری‌اند. هدف، اعطای آگاهانهٔ دسترسی و کاهش سوءاستفاده است، نه حذف دسترسی‌پذیری.
سه تهدیدی که نباید با هم اشتباه بگیریم
| روش | مهاجم چه می‌کند؟ | چه چیزی را نباید فرض کرد؟ |
|---|---|---|
| پنجره یا فرم جعلی | کاربر را به واردکردن اطلاعات در رابطی شبیه برنامهٔ اصلی ترغیب می‌کند | هر Overlay خودکار متن پنجرهٔ زیرین را نمی‌خواند |
| سرقت کلیک یا Tapjacking | کاربر را به لمس کنترل دیگری فریب می‌دهد | وجود یک لایهٔ شفاف به معنی ثبت همهٔ کلیدها نیست |
| سوءاستفاده از سرویس Accessibility | از قابلیت‌های مجاز سرویس برای مشاهده یا انجام عمل استفاده می‌کند | دسترسی به تمام نماها در همهٔ نسخه‌ها یکسان نیست |
راهنمای رسمی Tapjacking میان پوشاندن کامل و جزئی رابط تفاوت می‌گذارد. نوع پنجره، نسخهٔ اندروید و تنظیمات برنامه در نتیجه اثر دارند.
Accessibility چگونه می‌تواند به دادهٔ حساس برسد؟
سرویس دسترسی‌پذیری می‌تواند، در محدودهٔ قابلیت‌هایش، اطلاعات رابط را دریافت کند یا برای کاربر عملی انجام دهد. یک سرویس مخرب ممکن است از همین امکان سوءاستفاده کند. بنابراین فعال‌کردن آن برای برنامه‌ای که دلیل روشنی ندارد، تصمیم کم‌اهمیتی نیست.
اما ادعای «هر سرویس می‌تواند تمام متن هر برنامه را بخواند» بیش‌ازحد مطلق است. ساختار نماها، نحوهٔ ارائهٔ داده و محدودیت‌های سیستم‌عامل مهم‌اند. اندروید برای نماهای حساس قابلیت‌هایی مانند accessibilityDataSensitive دارد؛ استفاده و رفتار آن‌ها باید روی نسخهٔ هدف آزمایش شود. توضیح گوگل دربارهٔ محافظت از داده در برابر سرویس‌های مخرب.
FLAG_SECURE چه می‌کند و چه نمی‌کند؟
FLAG_SECURE برای محدودکردن اسکرین‌شات و نمایش محتوا روی خروجی‌های غیرامن کاربرد دارد. این پرچم به‌تنهایی قرارداد دسترسی‌پذیری، فرم جعلی یا همهٔ راه‌های استخراج متن را کنترل نمی‌کند. عکاسی از صفحه با دستگاه دیگر نیز مسئله‌ای جداست.
اندروید ابزارهای دیگری مانند HIDE_OVERLAY_WINDOWS برای کاهش پنجره‌های پوششی در اختیار برنامه قرار می‌دهد. هیچ‌کدام را نباید بدون بررسی سازگاری، محدودیت نسخه و تأثیر بر کاربران دارای نیازهای دسترسی‌پذیری به‌عنوان «دکمهٔ ضدجاسوسی» معرفی کرد. راهنمای محافظت از فعالیت‌های حساس.
چک‌لیست کاربر برای بررسی دسترسی‌ها
- در تنظیمات دستگاه، برنامه‌های دارای دسترسی‌پذیری، نمایش روی برنامه‌های دیگر و دسترسی به اعلان‌ها را جداگانه مرور کنید. نام مسیرها با سازنده و نسخه فرق می‌کند.
- برای هر مورد بپرسید چه قابلیت مشخصی به این دسترسی نیاز دارد. دسترسی یک صفحه‌خوان مورداعتماد با برنامهٔ چراغ‌قوهٔ ناشناس یکسان نیست.
- درخواست فوری برای فعال‌کردن دسترسی پس از نصب یک فایل ناشناس را نشانهٔ نیاز به بررسی بیشتر بدانید؛ صرف درخواست مجوز، اثبات بدافزاربودن نیست.
- اگر ظاهر صفحهٔ ورود مشکوک است، اطلاعات حساس وارد نکنید. برنامه را از مسیر معمول خودتان باز کنید و نشانی یا منبع نصب را بررسی کنید.
- پس از لغو دسترسی غیرضروری، عملکرد ابزارهای کمکی موردنیازتان را آزمایش کنید. امنیت نباید دستگاه را برای صاحبش غیرقابل‌استفاده کند.
اگر احتمال می‌دهید رمز یا نشست شما قبلاً افشا شده، لغو مجوز به‌تنهایی کافی نیست. از دستگاه مورداعتماد، نشست‌های فعال و راه‌های بازیابی حساب را بررسی کنید و رمزهای در معرض خطر را تغییر دهید.
توسعه‌دهنده چه چیزی را آزمایش کند؟
صفحات ورود، تأیید عملیات و نمایش اطلاعات حساس را جدا ارزیابی کنید. لمسِ پوشانده‌شده و پوشش جزئی را آزمایش کنید؛ صرف آزمون اسکرین‌شات کافی نیست. سپس همان مسیر را با صفحه‌خوان و ابزار کمکی واقعی بررسی کنید تا دفاع امنیتی دسترسی مشروع را نشکند.
در گزارش آزمون، نسخهٔ اندروید و برنامه، نوع سرویس، مجوزها و داده‌ای که واقعاً قابل‌مشاهده بوده ثبت شود. از یک آزمایش محدود نمی‌توان دربارهٔ همهٔ دستگاه‌ها نتیجه گرفت.
مرز رمزنگاری پیام‌رسان
مدل تهدید لیوارا دستگاه آلوده یا باز را خارج از تضمین حفاظت محتوایی قرار می‌دهد. بنابراین نام الگوریتم یا پساکوانتومی‌بودن تبادل کلید، دفاعی در برابر تمام سوءاستفاده‌های رابط کاربری نیست. حفاظت مسیر پیام، سلامت دستگاه و کنترل مجوزها را سه بررسی جدا در نظر بگیرید.
