پیاده سازی امنیت

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

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

برای تسهیل پذیرش این بهترین شیوه‌ها، در صورت امکان، تیم امنیتی Android آزمایش‌هایی را در مجموعه تست سازگاری Android (CTS) و Android Lint ترکیب می‌کند. ما پیاده‌کننده‌های دستگاه را تشویق می‌کنیم تا آزمایش‌هایی را انجام دهند که می‌تواند به سایر کاربران Android کمک کند (تست‌های مربوط به امنیت را در root/cts/tests/tests/security/src/android/security/cts مشاهده کنید).

فرآیند توسعه

از بهترین شیوه های زیر در فرآیندها و محیط توسعه خود استفاده کنید.

بررسی کد منبع

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

• Android Lint را با استفاده از Android SDK روی همه کدهای برنامه اجرا کنید و مشکلات شناسایی شده را اصلاح کنید.
• کد بومی باید با استفاده از یک ابزار خودکار که می تواند مسائل مدیریت حافظه مانند سرریز بافر و خطاهای یک به یک را شناسایی کند، تجزیه و تحلیل شود.
• سیستم ساخت اندروید از بسیاری از ضدعفونی‌کننده‌های LLVM مانند AddressSanitizer و UndefinedBehaviorSanitizer پشتیبانی می‌کند که می‌توانند برای این منظور استفاده شوند.

با استفاده از تست خودکار

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

• CTS به طور منظم با تست های امنیتی به روز می شود. برای تأیید سازگاری، جدیدترین نسخه CTS را اجرا کنید.
• CTS را به طور منظم در طول فرآیند توسعه اجرا کنید تا مشکلات را زود تشخیص داده و زمان اصلاح را کاهش دهید. Android از CTS به عنوان بخشی از یکپارچه سازی مداوم در فرآیند ساخت خودکار ما استفاده می کند، که چندین بار در روز ساخته می شود.
• سازندگان دستگاه باید تست امنیتی رابط‌ها، از جمله آزمایش با ورودی‌های نادرست (تست فازی) را خودکار کنند.

امضای تصاویر سیستم

امضای تصویر سیستم برای تعیین یکپارچگی دستگاه بسیار مهم است. بهترین شیوه ها:

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

برنامه های امضا (APK)

امضای برنامه نقش مهمی در امنیت دستگاه ایفا می کند و برای بررسی مجوزها و همچنین به روز رسانی نرم افزار استفاده می شود. هنگام انتخاب کلیدی برای استفاده برای امضای برنامه‌ها، مهم است که در نظر بگیرید که آیا یک برنامه فقط در یک دستگاه در دسترس خواهد بود یا در چندین دستگاه مشترک است. بهترین شیوه ها:

• برنامه ها نباید با کلیدی که برای عموم شناخته شده است امضا شوند.
• کلیدهایی که برای امضای برنامه‌ها استفاده می‌شوند باید به روشی مطابق با شیوه‌های استاندارد صنعت برای مدیریت کلیدهای حساس مدیریت شوند، از جمله HSM که دسترسی محدود و قابل ممیزی را فراهم می‌کند.
• برنامه ها نباید با کلید پلت فرم امضا شوند.
• برنامه هایی با نام بسته یکسان نباید با کلیدهای مختلف امضا شوند. این اغلب هنگام ایجاد یک برنامه برای دستگاه های مختلف رخ می دهد، به خصوص هنگام استفاده از کلید پلت فرم. اگر برنامه مستقل از دستگاه است، از کلید یکسانی در همه دستگاه‌ها استفاده کنید. اگر برنامه مخصوص دستگاه است، نام بسته های منحصر به فرد را برای هر دستگاه و کلید ایجاد کنید.

انتشار اپلیکیشن ها

Google Play به سازندگان دستگاه این امکان را می دهد که برنامه ها را بدون انجام به روز رسانی کامل سیستم به روز کنند. این می‌تواند پاسخ به مسائل امنیتی و ارائه ویژگی‌های جدید را تسریع کند، و همچنین راهی برای اطمینان از داشتن نام بسته منحصربه‌فرد برنامه شما ارائه می‌کند. بهترین شیوه ها:

• برنامه‌های خود را در Google Play آپلود کنید تا امکان به‌روزرسانی خودکار بدون نیاز به به‌روزرسانی کامل از طریق هوا (OTA) فراهم شود. برنامه‌هایی که آپلود می‌شوند اما منتشر نشده‌اند، مستقیماً توسط کاربران قابل دانلود نیستند، اما برنامه‌ها همچنان به‌روزرسانی می‌شوند. کاربرانی که قبلاً برنامه را نصب کرده‌اند، می‌توانند آن را مجدداً نصب و/یا در دستگاه‌های دیگر نصب کنند.
• یک نام بسته برنامه ایجاد کنید که به وضوح با شرکت شما مرتبط باشد، مانند استفاده از علامت تجاری شرکت.
• برنامه های منتشر شده توسط سازندگان دستگاه باید در فروشگاه Google Play آپلود شوند تا از جعل هویت بسته توسط کاربران شخص ثالث جلوگیری شود. اگر سازنده دستگاه بدون انتشار برنامه در فروشگاه Play، برنامه‌ای را روی دستگاهی نصب کند، توسعه‌دهنده دیگری می‌تواند همان برنامه را آپلود کند، از همان نام بسته استفاده کند و ابرداده برنامه را تغییر دهد. هنگامی که برنامه به کاربر ارائه می شود، این ابرداده نامرتبط می تواند سردرگمی ایجاد کند.

پاسخگویی به حوادث

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

• یک آدرس security@your-company.com یا مشابه ایجاد کنید و آن را عمومی کنید.
• اگر از یک مشکل امنیتی که بر سیستم عامل Android یا دستگاه‌های Android از چندین سازنده دستگاه تأثیر می‌گذارد مطلع شدید، باید با ارسال گزارش اشکال امنیتی با تیم امنیتی Android تماس بگیرید.

پیاده سازی محصول

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

جداسازی فرآیندهای ریشه

فرآیندهای ریشه بیشترین هدف حملات افزایش امتیاز هستند، بنابراین کاهش تعداد فرآیندهای ریشه خطر افزایش امتیاز را کاهش می دهد. CTS شامل یک تست اطلاعاتی است که فرآیندهای ریشه را فهرست می کند. بهترین شیوه ها:

• دستگاه ها باید حداقل کد لازم را به عنوان روت اجرا کنند. در صورت امکان، به جای پردازش ریشه، از یک فرآیند معمولی اندروید استفاده کنید. ICS Galaxy Nexus تنها شش پردازش ریشه دارد: vold، inetd، zygote، tf_daemon، ueventd و init. اگر فرآیندی باید به‌عنوان روت در دستگاه اجرا شود، فرآیند را در یک درخواست ویژگی AOSP مستند کنید تا بتوان آن را به صورت عمومی بررسی کرد.
• در صورت امکان، کد ریشه باید از داده های نامعتبر جدا شده و از طریق IPC قابل دسترسی باشد. به عنوان مثال، عملکرد ریشه را به یک سرویس کوچک که از طریق Binder قابل دسترسی است کاهش دهید و سرویس را با مجوز امضا در معرض یک برنامه کاربردی با امتیازات کم یا بدون دسترسی به ترافیک شبکه قرار دهید.
• فرآیندهای ریشه نباید در سوکت شبکه گوش دهند.
• فرآیندهای ریشه نباید یک زمان اجرا همه منظوره برای برنامه ها (مثلاً جاوا VM) ارائه دهند.

جداسازی برنامه های سیستم

به طور کلی، برنامه های از پیش نصب شده نباید با UID سیستم مشترک اجرا شوند. با این حال، اگر لازم است یک برنامه از UID مشترک سیستم یا سرویس ممتاز دیگری استفاده کند، برنامه نباید هیچ سرویس، گیرنده پخش یا ارائه دهنده محتوایی را صادر کند که توسط برنامه های شخص ثالث نصب شده توسط کاربران قابل دسترسی باشد. بهترین شیوه ها:

• دستگاه ها باید حداقل کد لازم را به عنوان سیستم اجرا کنند. در صورت امکان، به جای استفاده مجدد از UID سیستم، از یک فرآیند Android با UID خود استفاده کنید.
• در صورت امکان، کد سیستم باید از داده های نامعتبر جدا شده و IPC را فقط در معرض سایر فرآیندهای قابل اعتماد قرار دهد.
• فرآیندهای سیستم نباید در سوکت شبکه گوش دهند.

فرآیندهای جداسازی

Android Application Sandbox برنامه‌ها را با انتظار جدا شدن از سایر فرآیندهای روی سیستم، از جمله فرآیندهای ریشه و اشکال‌زدا، فراهم می‌کند. مگر اینکه اشکال زدایی به طور خاص توسط برنامه و کاربر فعال شده باشد، هیچ برنامه ای نباید آن انتظار را نقض کند. بهترین شیوه ها:

• فرآیندهای ریشه نباید به داده‌ها در پوشه‌های داده برنامه‌های کاربردی دسترسی داشته باشند، مگر اینکه از روش اشکال‌زدایی مستند Android استفاده کنند.
• فرآیندهای ریشه نباید به حافظه برنامه‌ها دسترسی داشته باشند، مگر اینکه از یک روش اشکال‌زدایی مستند Android استفاده کنند.
• دستگاه‌ها نباید شامل برنامه‌هایی باشند که به داده‌ها یا حافظه برنامه‌ها یا فرآیندهای دیگر دسترسی دارند.

ایمن سازی فایل های SUID

برنامه های جدید setuid نباید توسط برنامه های نامعتبر قابل دسترسی باشند. برنامه‌های Setuid اغلب محل آسیب‌پذیری‌هایی بوده‌اند که می‌توان از آنها برای دستیابی به دسترسی ریشه استفاده کرد، بنابراین سعی کنید دسترسی برنامه setuid را برای برنامه‌های غیرقابل اعتماد به حداقل برسانید. بهترین شیوه ها:

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

تأیید کننده CTS شامل یک آزمون اطلاعاتی است که فایل های SUID را فهرست می کند. برخی از فایل های setuid در آزمون های CTS مجاز نیستند.

ایمن کردن سوکت های گوش دادن

تست‌های CTS زمانی که دستگاه در حال گوش دادن به هر پورت و هر رابطی است، شکست می‌خورد. در صورت خرابی، Android تأیید می کند که بهترین روش های زیر در حال استفاده هستند:

• هیچ پورت گوش دادن روی دستگاه نباید وجود داشته باشد.
• پورت های گوش دادن باید بدون OTA غیرفعال شوند. این می تواند یک تغییر پیکربندی سرور یا کاربر-دستگاه باشد.
• فرآیندهای ریشه نباید در هیچ پورتی گوش دهند.
• فرآیندهای متعلق به UID سیستم نباید به هیچ پورتی گوش دهند.
• برای IPC محلی که از سوکت ها استفاده می کند، برنامه ها باید از یک سوکت دامنه یونیکس با دسترسی محدود به یک گروه استفاده کنند. یک توصیفگر فایل برای IPC ایجاد کنید و آن را برای یک گروه خاص یونیکس +RW کنید. هر برنامه مشتری باید در آن گروه یونیکس باشد.
• برخی از دستگاه‌های دارای چندین پردازنده (مانند رادیو/مودم جدا از پردازنده برنامه) از سوکت‌های شبکه برای برقراری ارتباط بین پردازنده‌ها استفاده می‌کنند. در چنین مواردی، سوکت شبکه مورد استفاده برای ارتباطات بین پردازنده باید از یک رابط شبکه ایزوله استفاده کند تا از دسترسی برنامه های غیرمجاز روی دستگاه جلوگیری کند (یعنی از iptables برای جلوگیری از دسترسی سایر برنامه های کاربردی روی دستگاه استفاده کنید).
• دیمون هایی که پورت های گوش دادن را مدیریت می کنند باید در برابر داده های نادرست مقاوم باشند. Google ممکن است با استفاده از یک کلاینت غیرمجاز و، در صورت امکان، از مشتری مجاز، آزمایش فازی را علیه پورت انجام دهد. هر گونه خرابی به عنوان باگ با شدت مناسب ثبت می شود.

ثبت داده ها

ثبت داده ها خطر مواجهه با آن داده ها را افزایش می دهد و عملکرد سیستم را کاهش می دهد. چندین رویداد امنیتی عمومی در نتیجه ثبت اطلاعات حساس کاربر توسط برنامه های نصب شده به طور پیش فرض در دستگاه های Android رخ داده است. بهترین شیوه ها:

• برنامه‌ها یا سرویس‌های سیستم نباید داده‌های ارائه‌شده از برنامه‌های شخص ثالث را که ممکن است شامل اطلاعات حساس باشد، ثبت کنند.
• برنامه ها نباید هیچ گونه اطلاعات شناسایی شخصی (PII) را به عنوان بخشی از عملکرد عادی ثبت کنند.

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

محدود کردن دسترسی به دایرکتوری

دایرکتوری‌های قابل نوشتن در جهان می‌توانند ضعف‌های امنیتی را معرفی کنند و برنامه‌ای را برای تغییر نام فایل‌های مورد اعتماد، جایگزینی فایل‌ها، یا انجام حملات مبتنی بر سیم‌لینک فعال کنند (ممکن است مهاجمان از یک پیوند نمادین به یک فایل برای فریب یک برنامه قابل اعتماد برای انجام اقداماتی که نباید استفاده می‌کنند) استفاده کنند. دایرکتوری‌های قابل نوشتن همچنین می‌توانند از حذف نصب یک برنامه از پاکسازی صحیح همه فایل‌های مرتبط با یک برنامه جلوگیری کنند.

به عنوان بهترین روش، دایرکتوری های ایجاد شده توسط سیستم یا کاربران ریشه نباید قابل نوشتن جهانی باشند. تست‌های CTS با آزمایش دایرکتوری‌های شناخته شده به اجرای این بهترین عمل کمک می‌کنند.

ایمن سازی فایل های پیکربندی

بسیاری از درایورها و سرویس‌ها به پیکربندی و فایل‌های داده ذخیره‌شده در فهرست‌هایی مانند /system/etc و /data متکی هستند. اگر این فایل‌ها توسط یک فرآیند ممتاز پردازش شوند و قابل نوشتن در جهان باشند، ممکن است یک برنامه با ایجاد محتوای مخرب در فایل قابل نوشتن جهان، از یک آسیب‌پذیری در فرآیند سوء استفاده کند. بهترین شیوه ها:

• فایل های پیکربندی مورد استفاده توسط فرآیندهای ممتاز نباید قابل خواندن در جهان باشند.
• فایل های پیکربندی مورد استفاده توسط فرآیندهای ممتاز نباید قابل نوشتن جهانی باشند.

ذخیره سازی کتابخانه های کد بومی

هر کدی که توسط فرآیندهای سازنده دستگاه ممتاز استفاده می شود باید در /vendor یا /system باشد. این فایل سیستم ها فقط به صورت خواندنی در بوت نصب می شوند. به عنوان بهترین روش، کتابخانه‌هایی که توسط سیستم یا سایر برنامه‌های دارای امتیاز بالا نصب شده روی دستگاه استفاده می‌شوند نیز باید در این فایل‌سیستم‌ها باشند. این می تواند از یک آسیب پذیری امنیتی جلوگیری کند که به مهاجم اجازه می دهد کدی را که یک فرآیند ممتاز اجرا می کند کنترل کند.

محدود کردن دسترسی درایور دستگاه

فقط کدهای قابل اعتماد باید به درایورها دسترسی مستقیم داشته باشند. در صورت امکان، معماری ترجیحی ارائه یک شبح تک منظوره است که پروکسی را به درایور فراخوانی می کند و دسترسی راننده را به دیمون محدود می کند. به عنوان بهترین روش، گره‌های دستگاه درایور نباید قابل خواندن یا نوشتن جهانی باشند. تست‌های CTS با بررسی نمونه‌های شناخته شده درایورهای در معرض دید، به اجرای این بهترین عمل کمک می‌کنند.

غیرفعال کردن ADB

پل اشکال زدایی اندروید (adb) یک ابزار با ارزش توسعه و اشکال زدایی است، اما برای استفاده در محیط های کنترل شده و امن طراحی شده است و نباید برای استفاده عمومی فعال شود. بهترین شیوه ها:

• ADB باید به طور پیش فرض غیرفعال باشد.
• ADB باید از کاربر بخواهد که آن را قبل از پذیرش اتصالات روشن کند.

باز کردن قفل بوت لودرها

بسیاری از دستگاه‌های Android از باز کردن قفل پشتیبانی می‌کنند و به مالک دستگاه امکان می‌دهند پارتیشن سیستم را تغییر داده و/یا یک سیستم عامل سفارشی نصب کنند. موارد استفاده رایج شامل نصب رام شخص ثالث و انجام توسعه در سطح سیستم بر روی دستگاه است. به عنوان مثال، یک مالک دستگاه Google Nexus می‌تواند برای شروع فرآیند باز کردن fastboot oem unlock اجرا کند، که پیام زیر را به کاربر ارائه می‌دهد:

به عنوان بهترین روش، دستگاه‌های اندرویدی قابل باز شدن باید قبل از باز شدن قفل، همه داده‌های کاربر را به‌طور ایمن پاک کنند. عدم حذف صحیح همه داده‌ها هنگام باز کردن قفل ممکن است به یک مهاجم نزدیک به فیزیکی اجازه دسترسی غیرمجاز به داده‌های محرمانه کاربر Android را بدهد. برای جلوگیری از افشای داده‌های کاربر، دستگاهی که از باز کردن قفل پشتیبانی می‌کند باید آن را به درستی پیاده‌سازی کند (نمونه‌های متعددی را دیده‌ایم که سازندگان دستگاه به‌طور نادرست باز کردن قفل را اجرا کرده‌اند). یک فرآیند باز کردن قفل به درستی اجرا شده دارای ویژگی های زیر است:

• هنگامی که فرمان باز کردن قفل توسط کاربر تأیید شد، دستگاه باید بلافاصله پاک کردن اطلاعات را شروع کند. پرچم unlocked نباید تا زمانی که حذف ایمن کامل شود تنظیم شود.
• اگر حذف ایمن قابل انجام نباشد، دستگاه باید در حالت قفل بماند.
• اگر توسط دستگاه بلوک زیرین پشتیبانی می شود، باید ioctl(BLKSECDISCARD) یا معادل آن استفاده شود. برای دستگاه‌های eMMC، این به معنای استفاده از دستور پاک کردن امن یا برش امن است. برای eMMC 4.5 و جدیدتر، این به معنای استفاده از یک Erase یا Trim معمولی و به دنبال آن یک عملیات Sanitize است.
• اگر BLKSECDISCARD توسط دستگاه بلوک زیرین پشتیبانی نمی شود، باید به جای آن ioctl(BLKDISCARD) استفاده شود. در دستگاه‌های eMMC، این یک عملیات Trim معمولی است.
• اگر BLKDISCARD پشتیبانی نمی‌شود، بازنویسی دستگاه‌های بلوک با تمام صفرها قابل قبول است.
• کاربر نهایی باید این گزینه را داشته باشد که قبل از فلش کردن پارتیشن، اطلاعات کاربر را پاک کند. به عنوان مثال، در دستگاه های Nexus، این کار از طریق دستور fastboot oem lock انجام می شود.
• یک دستگاه ممکن است از طریق فیوز یا مکانیسمی مشابه، قفل باز و/یا قفل مجدد دستگاه را ضبط کند.

این الزامات تضمین می کند که تمام داده ها پس از اتمام عملیات باز کردن قفل از بین می روند. عدم اجرای این حفاظت ها یک آسیب پذیری امنیتی در سطح متوسط ​​تلقی می شود.

دستگاهی که قفل آن باز است ممکن است متعاقباً با استفاده از فرمان fastboot oem lock قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال اگر دستگاه دوباره آنلاک شود، داده های کاربر پاک خواهند شد).