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

تیم امنیتی 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 قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال اگر دستگاه دوباره آنلاک شود، داده های کاربر پاک خواهند شد).

تیم امنیتی 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 قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال اگر دستگاه دوباره آنلاک شود، داده های کاربر پاک خواهند شد).

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

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

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

فرآیند توسعه

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

کد منبع را مرور کنید

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

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

از تست خودکار استفاده کنید

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

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

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

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

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

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

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

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

انتشار برنامه ها

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

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

پاسخ به حوادث

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

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

محصولات را پیاده سازی کنید

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

فرآیندهای ریشه را جدا کنید

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

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

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

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

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

فرایندها

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

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

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

برنامه های جدید SETUID نباید توسط برنامه های غیرقابل اعتماد قابل دسترسی باشد. برنامه های SETUID غالباً محل آسیب پذیری ها بوده اند که می توانند برای دستیابی به دسترسی ریشه مورد استفاده قرار گیرند ، بنابراین تلاش کنید تا در دسترس بودن برنامه SETUID به برنامه های غیرقابل اعتماد را به حداقل برسانید. بهترین شیوه ها:

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

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

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

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

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

داده های ثبت نام

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

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

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

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

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

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

پرونده های پیکربندی ایمن

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

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

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

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

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

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

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

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

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

باز کردن bootloaders

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

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

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

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

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

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

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

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

فرآیند توسعه

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

کد منبع را مرور کنید

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

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

از تست خودکار استفاده کنید

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

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

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

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

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

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

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

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

انتشار برنامه ها

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

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

پاسخ به حوادث

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

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

محصولات را پیاده سازی کنید

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

فرآیندهای ریشه را جدا کنید

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

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

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

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

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

فرایندها

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

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

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

برنامه های جدید SETUID نباید توسط برنامه های غیرقابل اعتماد قابل دسترسی باشد. برنامه های SETUID غالباً محل آسیب پذیری ها بوده اند که می توانند برای دستیابی به دسترسی ریشه مورد استفاده قرار گیرند ، بنابراین تلاش کنید تا در دسترس بودن برنامه SETUID به برنامه های غیرقابل اعتماد را به حداقل برسانید. بهترین شیوه ها:

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

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

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

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

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

داده های ثبت نام

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

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

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

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

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

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

پرونده های پیکربندی ایمن

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

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

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

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

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

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

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

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

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

باز کردن bootloaders

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

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

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

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

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