یکی از دغدغه های برنامه نویس ها و توسعه دهنده های اندروید امنیت اپ هایی است که میسازند. پس همه برنامه نویس ها باید با نکته های امنیتی که برای اپلیکیشن های آنها ممکن است اتفاق بیفتد را بشناسند و بتوانند راهکار های درستی برای مقابله با آنها پیاده سازی کنند. در این مقاله از بلاگ برنامه چی همه نکته هایی که برای امنیت اپ به آنها نیاز داریم را با هم بررسی میکنیم. با ما همراه باشید.
در این نوشته درباره روش های ایمن ذخیره سازی داده، استفاده از Permission ها، استفاده از شبکه، مدیریت داده های کاربر، استفاده از Intent ها، استفاده از Service ها و امنیت سیستم عامل و ماشین مجازی اندروید صحبت کردیم. لیست تیترهای این مقاله را در باکس زیر میتوانید مشاهده کنید:
امنیت سیستم عامل اندروید
سیستم عامل اندروید دارای ویژگی های امنیتی داخلی است که تاثیر اشکلات امنیتی موجود در اپلیکیشن ها را تا حد بسیار زیادی کاهش میدهد. یعنی کل سیستم طوری طراحی شده است که شما بتوانید با استفاده از Permission های ساده اقدام به تولید اپلیکیشن کنید و تصمیمات سخت برای امنیت اپ را به اندروید واگذار نمایید.
ویژگی های امنیتی زیر به شما کمک میکنند که بتوانید امنیت اپ خودتان را بسیار بیشتر ارتقا بدهید:
- جعبه شن سیستم عامل اندروید یا Android Application Sandbox اپلیکیشن شما و داده هایش را از دیگر نرم افزارها ایزوله میکند.
- یک فریم ورک مخصوص اپلیکیشن که با استفاده از آن میتوانید ویژگی های امنیتی رایج مانند کریپتوگرافی، Permission ها و IPC ایمن را به راحتی در اپلیکیشن های خودتان پیاده سازی کنید.
- تکنولوژی هایی مانند ASLR، NX، ProPolice، safe_iop، OpenBSD dlmalloc، Open BSD calloc و Linux mmap_min_addr که ریسک های مدیریت حافظه را به حداقل میرسانند.
- یک سیستم کدگذاری فایل که میتواند از اطلاعات فایل ها در دستگاه های گم شده یا دزدیده شده محافظت کند.
- مجوز هایی که کاربر به اپلیکیشن ها میدهد تا بتواند دسترسی این نرم افزار ها به اطلاعات و قسمت های خاص دستگاه را کنترل کند.
- مجوز هایی که مخصوص اپلیکیشن هستند تا بتوانند داده های هر اپلیکیشن را کنترل و بررسی کنند.
یکی از نکته های بسیار مهم این است که شما باید با بهترین راهکارهای تامین امنیت اپلیکیشن های اندرویدی آشنا باشید. میتوانید این مقاله را از این لینک مطالعه کنید. با دنبال کردن این راهکار ها و عادت کردن به آنها، میتوانید ارور ها و خطرات ناخواسته را در اپلیکیشن های خود کاهش بدهید و از اثرات منفی آن ها بر کاربرانتان در امان بمانید.
ذخیره سازی داده ها
معمولا رایج ترین نگرانی که درباره امنیت اپ های اندروید وجود دارد، این است که آیا دیگر اپلیکیشن ها به داده هایی که اپلیکیشن شما در حافظه ذخیره کرده است دسترسی دارند یا نه؟ میخواهیم در این قسمت این پرسش را بررسی کنیم و به جواب مناسبی برسیم. بهتر است از روش های ذخیره سازی داده ها در اندروید شروع کنیم. در سیستم عامل اندروید، سه روش پایه ای برای ذخیره داده ها در حافظه وجود دارد:
- حافظه داخلی (Internal Sotrage)
- حافظه خارجی (External Storage)
- ارائه دهندگان محتوا (Content Providers)
در ادامه میخواهیم بررسی کنیم که مشکلات امنیتی هرکدام از این روش ها برای ذخیره کردن داده ها چیست.
استفاده از حافظه داخلی
بصورت پیشفرض، فایل هایی که روی حافظه داخلی ذخیره میکنید، فقط برای اپلیکیشن خودتان قابل دسترسی هستند. این مدل حفاظت از داده ها توسط سیستم عامل اندروید پیاده سازی میشود و برای بسیاری از اپلیکیشن ها کافی می باشد.
پس همیشه در نظر داشته باشید که از مود های MODE_WORLD_WRITABLE یا MODE_WORLD_READABLE برای فایل های IPC استفاده نکنید. زیرا نه تنها این مود ها از محدود کردن دسترسی به داده ها توسط اپلیکیشن های خاص پشتیبانی نمیکنند، بلکه هیچ فرمتی برای کنترل داده ها نیز ارائه نمیدهند. اگر میخواهید داده های خود را برای پردازش دیگر اپلیکیشن ها به اشتراک بگذارید، بهتر است که از ارائه دهندگان محتوا (Content Provider) ها استفاده کنید. با استفاده از این روش میتوانید داده های یک اپلیکیشن را با اپلیکیشن های دیگر به اشتراک بگذارید و همچنین میتوانید مجوز های داینامیک، برای موارد استفاده مختلف ایجاد کنید.
برای محافظت بیشتر از داده هایی که حساسیت بالایی دارند، میتوانید با استفاده از کتابخانه Security، فایل های محلی اپلیکیشن را Encrypt کنید. این کار میتواند از داده های دستگاه گم شده یا دزدیده شده، حتی اگر از سیستم فایل های کدگذاری شده استفاده نکرده باشد نیز محافظت کند.
استفاده از حافظه خارجی
فایل هایی که روی حافظه های خارجی مانند کارت های SD ذخیره میشوند، برای همه اپلیکیشن ها و افراد دیگر قابل دسترسی و ویرایش هستند. به دلیل اینکه حافظه های خارجی ممکن است توسط کاربر از دستگاه خارج شوند و یا به وسیله اپلیکیشن های دیگر تغییر کنند، برای امنیت اپ، نباید اطلاعات حساس را روی آن ها ذخیره کنیم.
برای اینکه فایل ها را روی حافظه خارجی بصورت ایمن ذخیره کنیم، میتوانیم از کتابخانه Security و کلاس EncryptedFile که درون همان کلاس قرار دارد استفاده کنیم.
همانطور که گفتیم، داده های موجود در حافظه خارجی ممکن است توسط دیگر اپلیکیشن ها دستکاری شوند. برای همین وقتی که میخواهیم داده هایی که قبلا روی این حافظه ذخیره کردیم یا داده هایی که از منابع خارجی می آیند را در اپلیکیشن خودمان استفاده کنیم، باید روند اعتبار سنجی داده ها را برای آنها پیاده سازی کرده باشیم. یعنی همیشه قبل از استفاده از این فایل ها باید چک کنیم محتویات آنها دستکاری شده یا ناقص نباشند که عملکرد اپلیکیشن اختلال پیدا نکند.
به دلیل وجود بارگذاری پویا (Dynamic Loading) شما نباید فایل هایی که قابلیت اجرا شدن دارند (فایل های Executable) و فایل های کد را روی حافظه خارجی ذخیره کنید. اگر اپلیکیشن شما نیاز داشت که فایل های کد و قابل اجرا را از حافظه خارجی دریافت کند، این فایل ها باید Sign شده و از لحاظ رمزنگاری تایید شده باشند.
استفاده از ارائه دهنده محتوا (Content Providers)
Content Provider ها یک مکانیزم ساختار یافته برای حافظه را در دسترس ما قرار میدهند که با استفاده از آن میتوانیم مشخص کنیم داده ها فقط برای اپلیکیشن ما محدود شوند یا اینکه اجازه دسترسی به آنها را توسط اپلیکیشن های دیگر بدهیم. اگر نمیخواهید اپلیکیشن های دیگر به Content Provider شما دسترسی داشته باشند، باید آن را با استفاده از android:exported=false درون فایل مانیفست پروژه خودتان نشانه گذاری کنید. اگر میخواهید اجازه دسترسی به اپلیکیشن های دیگر داده شود، میتوانید از android:exported=true استفاده کنید. با این کار بقیه اپلیکیشن ها به داده های ذخیره شده دسترسی خواهند داشت.
وقتی که در حال ساخت یک ContentProvider از نوع Exported هستید، میتوانید یک Permission تکی یا مجوز های خاص برای دسترسی و ویرایش داده ها ایجاد کنید. شما باید این مجوز ها را برای آن اپلیکیشن هایی که به داده ها برای انجام تسک های خودشان نیاز دارند محدود کنید تا امنیت اپ به خطر نیفتد.
اگر میخواهید از Content Provider برای به اشتراک گذاشتن داده ها بین اپلیکیشن های خودتان استفاده کنید، بهتر است که مقدار ویژگی android:protectionLevel را برابر signature قرار بدهید. مجوز هایی که از نوع Signature هستند نیاز به تایید کاربر ندارند. به همین دلیل در سناریو هایی که داده ها بین اپلیکیشن هایی که با یک کلید یکسان Sign شده اند به اشتراک گذاشته میشوند، تجربه کاربری بهتری را برای کاربران به وجود می آورد.
علاوه بر اینها Content Provider ها میتوانند کنترل بیشتری را روی دسترسی ها و امنیت اپ اعمال کنند. شما میتوانید با تعریف ویژگی android:grantUriPermissions و استفاده از پرچم های FLAG_GRANT_READ_URI_PERMISSION و FLAG_GRANT_WRITE_URI_PERMISSION روی آبجکت Intent که کامپوننت مورد نظر را فعال میکند، این کار را انجام بدهید. حتی حوزه دید این مجوز ها میتوانند با استفاده از المان <grant-uri-permission> محدودتر هم شوند.
وقتی که میخواهید به Content Provider دسترسی داشته باشید، بهتر است از متد هایی که با استفاده از پارامترهای خاص کوئری میزنند استفاده کنید. مانند متدهای زیر:
query(), update(), delete()
استفاده از این متدها باعث میشود که تزریق های ناخواسته دیتا توسط منابع تایید نشده به دیتابیس های اپلیکیشن ما قطع شود. البته این نکته را در نظر داشته باشید که اگر آرگومان selection قبل از استفاده از این متد ها، با پیوند جدول ها (Concat) ساخته شده باشد، استفاده از متد های پارامتر پذیر برای تامین امنیت اپ کافی نیست.
درباره مجوز های نوشتن (write permissions) و امنیت آنها احساس اشتباه نداشته باشید و همیشه جانب احتیاط را رعایت کنید. مجوز های نوشتن، به دستورات SQL این قدرت را میدهند که با استفاده از شرط های WHERE که به صورت خلاقانه نوشته شده اند، داده های ورودی را تایید و اعتبار سنجی کنند و نتیجه را برگردانند. به عنوان مثال، یک حمله کننده ممکن است برای بررسی وجود یک شماره تلفن خاص در لیست تماس ها اقدام کند. برای این کار میتواند دستوری بنویسد که فقط در صورتی که آن شماره در لیست وجود داشته باشد، یک سطر به لیست تماس ها اضافه کند. یعنی اگر ساختار داده های Content Provider قابل پیش بینی باشد، مجوز نوشتن میتواند هردو Permission خواندن و نوشتن را ارائه بدهد.
استفاده از Permission ها
ساختار اندروید به گونه ای است که اپلیکیشن ها را نسبت به هم ایزوله میکند. به دلیل همین ساختار، وقتی که شما میخواهید داده ها و منابع خاصی را به اشتراک بگذارید، باید بصورت صریح این کار را انجام بدهید. اپلیکیشن ها باید با تعریف Permission های مخصوص، قابلیت های خاصی که به آنها نیاز دارند و توسط SandBox اندروید در اختیار آنها قرار نمیگیرد را به خود اضافه کنند. مثلا استفاده از قابلیت هایی مانند دسترسی به ماژول دوربین از این طریق انجام میشود.
درخواست Permission
شما باید برای تامین امنیت اپ، تعداد مجوز هایی که اپلیکیشن درخواست میکند را به حداقل برسانید. محدود کردن دسترسی به مجوز های حساس باعث کم شدن ریسک سو استفاده ناخواسته از مجوزها، بهبود اختیار کاربری و همچنین کم کردن مطلوبیت برای حمله کننده ها میشود. پس اگر اپلیکیشن شما نیاز به مجوز خاصی برای کارکرد های خود ندارد، آن مجوز را درخواست نکنید. اگر هم به ویژگی خاصی نیاز دارید که اپلیکیشن بدون آن نمیتواند اجرا شود، آن مجوز را با استفاده از المان <uses-permission> درون فایل منیفست، به اپلیکیشن اضافه کنید.
اگر راهی وجود دارد که اپلیکیشن خود را طوری طراحی کنید تا نیاز به هیچ مجوزی نداشته باشد، همین راه را انتخاب کنید. به عنوان مثال، به جای اینکه با دسترسی به اطلاعات دستگاه، اقدام به ساخت یک Identifier یکتا کنید، میتوانید یک GUID برای اپلیکیشن خودتان بسازید. یا مثلا به جای ذخیره کردن داده ها روی حافظه خارجی (که نیاز به Permission دارد)، داده ها را روی حافظه داخلی ذخیره کنید. با این کار امنیت اپ کمتر به خطر می افتد.
علاوه بر درخواست Permission، اپلیکیشن شما میتواند از المان <permission> برای ایمن کردن IPC هایی که حساس هستند و امکان انتشار برای دیگر اپلیکیشن ها را دارند (مانند یک Content Provider) استفاده کنید. در حقیقت ما پیشنهاد میکنیم از کنترل کننده های دسترسی (Access Controls) به جای درخواست مجوز از کاربر استفاد کنید. زیرا گاهی Permission ها برای کاربر گیج کننده میشوند. به عنوان مثال، برای ارتباط از طریق IPC بین اپلیکیشن هایی که توسط یک توسعه دهنده منتشر شده اند، از سطح محافظت Singature استفاده کنید.
داده هایی که توسط مجوز ها محافظت میشوند را لو ندهید. این اتفاق زمانی رخ میدهد که اپلیکیشن شما داده ها را روی IPC افشا کند که فقط چون اپلیکیشن به آن اطلاعات دسترسی دارد، در دسترس دیگران نیز قرار میگیرد. کلاینت های اینترفیس IPC اپلیکیشن شما شاید همان مجوزهای مورد نیاز برای دسترسی به داده ها را نداشته باشند.
ساخت Permission ها
در حالت عادی، شما باید همه تلاشتان را بکنید که کمترین Permission ها را درخواست کنید و همچنین با این کار امنیت اپ را حفظ کنید. ساخت مجوز های جدید برای اکثر اپلیکیشن ها، کاری غیر عادی است. زیرا Permission هایی که از قبل در سیستم وجود دارند، بیشتر نیاز ها و وضعیت های مورد نیاز شما را پوشش میدهند. هرجا که مناسب بود، دسترسی ها را با استفاده از Permission های موجود بررسی کنید.
اگر مجبور هستید که یک Permission جدید بسازید، اول بررسی کنید که آیا میتوانید وظیفه های اپلیکیشن را با محافظت سطح Signature انجام بدهید. مجوز های Signature برای کاربر قابل مشاهده نیستند و فقط به اپلیکیشن هایی که توسط یک توسعه دهنده یکسان تولید شده اند اجازه دسترسی میدهند. اگر هنوز هم به Permission جدید نیاز دارید، میتوانید المان <permission> را به فایل manifest پروژه اضافه کنید.
اپلیکیشن هایی که میخواهند از این مجوز جدید استفاده کنند، هرکدام باید در فایل Manifest خود، المان <uses-permission> را اضافه کنند. همچنین میتوانید Permission ها را به صورت پویا با استفاده از متد addPermissions اضافه کنید. اگر یک مجوز با سطح محافظت Dangerous (خطرناک) بسازید، تعدادی از پیچیدگی ها و ملاحظات برای امنیت اپ هستند که باید آنها را در نظر بگیرید:
- هر Permission باید دارای یک متن باشد (یک String) که به کاربر بصورت خلاصه توضیح بدهد چه تصمیم امنیتی باید بگیرد.
- این متن خلاصه، باید به همه زبان های ممکن ترجمه شود و در اپلیکیشن قرار بگیرد.
- کاربران میتوانند به دلیل اینکه یک مجوز گمراه کننده یا خطرناک باشد، تصمیم بگیرند اپلیکیشن را نصب نکنند.
سناریو هایی وجود دارند که اپلیکیشن های دیگر ممکن است نصب شده باشند و برای مجوزهایی درخواست بدهند که سازنده این مجوز ها هنوز نصب نشده باشند. (یعنی فرض کنید یکی از اپلیکیشن های ما یک مجوز درست میکند، اپلیکیشن دوم ما به آن مجوز نیاز دارد، ممکن است کاربر ابتدا اپلیکیشن دوم را نصب کند، در حالی که هنوز اپلیکیشن اول نصب نشده است).
همه این سناریو ها باعث میشوند چالش های غیرمعمول برای شما به عنوان یک توسعه دهنده به وجود بیاید در حالی که کاربران خودتان را هم گمراه میکنید. به همین دلیل ما پیشنهاد میکنیم هرگز از مجوز هایی با سطح حفاظت Dangerous ایجاد نکنید.
استفاده از شبکه (Network)
تراکنش های شبکه، بصورت ذاتی برای امنیت اپ خطرناک هستند. زیرا این تراکنش ها اطلاعاتی را انتقال میدهند که برای کاربر ضروری یا خصوصی هستند. مردم امروز مرتبا در حال آگاه شدن از خطرات و ریسک های استفاده از دستگاه های موبایل هستند، مخصوصا وقتی که این دستگاه ها تراکنش های اینترنتی انجام میدهند. پس این نکته بسیار مهم است که اپلیکیشن شما همه اقدامات امنیتی برای محافظت همیشگی از اطلاعات کاربران را انجام بدهد.
استفاده از شبکه با استفاده از IP
ارتباط با شبکه در اندروید، تفاوت زیادی با دیگر محیط های لینوکسی ندارد. مسئله اصلی این است که مطمئن شویم که برای داده های حساس، از پروتکل های درست استفاده میکنیم. مانند HttpsURLConnection برای ترافیک وب امن. شما همیشه باید از پروتکل HTTPS به جای HTTP در سرور هایی که از این پروتکل پشتیبانی میکنند استفاده کنید. زیرا دستگاه های موبایل معمولا به شبکه هایی متصل میشوند که ایمنی بالایی ندارند، مانند وای فای های مختلف که در مکان های زیادی وجود دارند.
ارتباطات تایید شده، کدگذاری شده و Socket-level میتوانند به راحتی با استفاده از کلاس SSLSocket پیاده سازی بشوند. همانطور که گفتیم، دستگاه های موبایل به شبکه های نا امن متصل میشوند، به همین دلیل شدیدا توصیه میکنیم همه ارتباطات شبکه ای اپلیکیشن ها از طریق شبکه های امن صورت بگیرند. یعنی قید هایی برای امنیت اپ و استفاده ایمن از اینترنت را در اپلیکیشن خودتان پیاده سازی کنید.
بعضی اپلیکیشن ها از پورت های شبکه localhost برای مدیریت کردن IPC های حساس استفاده میکنند. شما نباید از این روش برای تامین امنیت اپ استفاده کنید، زیرا این اینترفیس ها توسط دیگر اپلیکیشن های دستگاه قابل دسترسی هستند. به جای این کار، از یک مکانیزم Android IPC (مثلا یک Service) استفاده کنید که امکان احراز هویت را به شما میدهد. حتی Bind کردن به INADDR_ANY بدتر از استفاده از loopback هاست، زیرا در این صورت اپلیکیشن شما ممکن است از هرجایی درخواست های خطرناک دریافت کند.
مطمئن شوید که به هیچ داده دانلود شده از پروتکل HTTP یا دیگر پروتکل های غیر ایمن اعتماد نکنید. این مسئله شامل اعتبار سنجی داده های ورودی WebView و هرگونه پاسخی که به intent های فراخوان شده از طریق HTTP داده میشود نیز می باشد.
استفاده از شبکه های تلفنی
پروتکل SMS در اصل برای ارتباطات کاربر به کاربر ساخته شده و برای ارسال داده توسط اپلیکیشن ها مناسب نیست. به دلیل محدودیت های SMS، شما باید از سرویس پیام رسان ابری گوگل به نام Google Cloud Messaging یا GCM و ارتباط با شبکه از طریق IP برای ارسال پیام های حاوی داده از وب سرور به اپلیکیشن خودتان روی دستگاه کاربر استفاده کنید.
این نکته را فراموش نکنید که که SMS نه تنها کدگذاری شده نیست، بلکه حتی روی شبکه خود دستگاه هم کاملا تایید نشده است. به عبارت دیگر، هر دریافت کننده SMS باید این انتظار را داشته باشد که یک بدافزار ممکن است برای اپلیکیشن شما SMS را فرستاده باشد تا امنیت اپ را به خطر بیاندازد. پس برای انجام دستورات حساس، به اطلاعات SMS های تایید نشده اصلا اعتماد نکنید.
همچنین باید این مسئله را در نظر داشته باشید که SMS ها میتوانند روی شبکه مورد شنود قرار بگیرند. روی دستگاه هایی که با سیستم عامل اندروید کار میکنند، پیام های SMS به عنوان Broadcast Intent منتشر میشوند. یعنی ممکن است این پیام ها توسط اپلیکیشن هایی که دارای مجوز READ_SMS باشند، دریافت شده و خوانده شوند.
اعتبار سنجی ورودی ها
عدم وجود اعتبار سنجی کافی برای ورودی ها، یکی از مشکلات رایج امنیت اپ میباشد که اپلیکیشن ها روی همه پلتفرم های موجود، به آن آلوده هستند. سیستم عامل اندروید دارای ویژگی هایی در پلتفرم خود میباشد که ریسک قرار گرفتن اپلیکیشن در معرض اشکالات اعتبار سنجی ورودی ها را کاهش میدهد و شما باید هرجایی که ممکن است، از این ویژگی ها استفاده کنید. همچنین استفاده از زبان های برنامه نویسی ایمن، احتمال به وجود آمدن این مدل خطرات را کاهش میدهد.
اگر از زبان های برنامه نویسی بومی استفاده میکنید، هر داده ای که از فایل ها، از شبکه، یا از IPC دریافت شده اند، پتانسیل این را دارد که یک مشکل امنیتی به وجود بیاورد. رایج ترین مشکلات امنیتی Buffer Overflows، Use After Free و Off-by-one errors هستند. اندروید دارای تکنولوژی هایی مانند ASLR و DEP است که خطر به وجود آمدن این مشکلات برای امنیت اپ را کاهش میدهند. اما این تکنولوژی ها مشکلات لایه های زیری را حل نمیکنند. شما باید برای ایمن کردن اپلیکیشن خودتان، pointer ها و Buffer ها را به دقت مدیریت کنید.
زبان های پویا و String Base مانند جاوا اسکریپت و SQL نیز به دلیل وجود کاراکتر های فرار و تزریق اسکریپت (Script Injection) در معرض اینگونه تهدیدات قرار دارند.
اگر شما در کوئری های SQL یا Content Provider داده هم ارسال میکنید، تزریق SQL شاید به یک مشکل برای اپلیکیشن شما تبدیل بشود. بهترین دفاع برای این مشکل، استفاده از کوئری های پارامتری شده است. در مورد این کار در بخش های قبلی همین مقاله توضیح دادیم. محدود کردن Permission ها به مدل های Read-only و Write-only هم میتواند خطرات امنیتی را کاهش بدهد.
اگر امکان استفاده از ویژگی های امنیتی بالا برای شما وجود ندارد، باید از ساختار درست داده ها مطمئن شوید و کاری کنید همه داده ها در فرمت های از قبل پیش بینی شده ارسال و دریافت شوند. در حالیکه شاید مسدود کردن کاراکترهای خاص یا جایگزین کردن کاراکتر ها، یک استراتژی موثر باشد. اما در عمل باعث به وجود آمدن ارور های زیادی میشوند و باید در صورت امکان از آنها پرهیز شود.
مدیریت کردن داده های کاربر
بصورت کلی، بهترین راهکار برای تامین امنیت داده های کاربر این است که استفاده از API هایی که به داده های حساس کاربر دسترسی دارند را به حداقل برسانیم. اگر به داده های کاربر دسترسی دارید و میتوانید بدون ذخیره کردن یا انتقال آنها، وظیفه های اپلیکیشن را انجام بدهید، هیچوقت برای ذخیره کردن یا انتقال این داده ها اقدام نکنید. همچنین همیشه باید راه هایی را در نظر بگیرید که از Hash یا فرمت های داده ای غیر قابل برگشت استفاده کنید. به عنوان مثال اپلیکیشن شما میتواند از آدرس Hash یک آدرس ایمیل به عنوان کلید اصلی استفاده کند تا نیاز نباشد خود آدرس ایمیل را ذخیره کند یا انتقال بدهد. این کار امکان لو رفتن ناخواسته اطلاعات را کمتر میکند و همچنین میتواند از حملات هکر ها برای دزدیدن اطلاعات اپ جلوگیری کند.
اگر اپلیکیشن شما به نام کاربری و پسورد کاربران دسترسی داشته باشد، ممکن است مقامات قضایی از شما بخواهند در مورد حریم خصوصی کاربران و موارد استفاده از این داده ها توضیحاتی ارائه بدهید. پس استفاده از بهترین راهکار ها برای کم کردن دسترسی به داده های کاربر، میتواند پیچیدگی های کار شما را هم کمتر کند.
باید این مسئله را هم در نظر داشته باشید که ممکن است اپلیکیشن شما بصورت ناخواسته داده های شخصی افراد را به بیزینس های دیگر مانند پلتفرم های تبلیغاتی و سرویس هایی که اپ از آنها استفاده میکند لو بدهد. اگر دلیل اینکه یک سرویس یا یک کامپوننت چرا باید داده های شخصی را از شما بخواهد نمیدانید، این داده ها را به هیچ وجه در اختیار آنها قرار ندهید. پس کاهش دسترسی به داده های شخصی توسط اپلیکیشن، پتانسیل به وجود آمدن مشکلات پیچیده برای امنیت اپ، مانند این مورد را کمتر میکند.
اگر اپلیکیشن شما نیاز دارد که به اطلاعات حساس دسترسی داشته باشد، بررسی کنید که باید این داده ها را به یک سرور بفرستید یا میتوانید همه عملیات را در سمت کلاینت انجام بدهید. سعی کنید همه کارهایی که ممکن است را در سمت کلاینت انجام بدهید و اطلاعات کاربران را برای سرور ارسال نکنید. همچنین مراقب باشید اطلاعات کاربران را با دیگر اپلیکیشن های موجود در دستگاه از طریق IPC، فایل های World-writable یا سوکت های شبکه، به اشتراک نگذارید.
اگر نیاز به استفاده از GUID داشتید، یک عدد طولانی و یکتا تولید کنید و آن را ذخیره نمایید. از شماره های موجود در خود گوشی مانند شماره تلفن و IMEI برای این کار استفاده نکنید، حتی ترکیب این شماره ها با اطلاعات شخصی نیز راهکار مناسبی نمیباشد.
مراقب اطلاعاتی که درون Log های دستگاه قرار میدهید باشید. در سیستم عامل اندروید، Log ها یکی از منابعی هستند که در دسترس همه اپلیکیشن هایی که مجوز READ_LOGS را داشته باشند قرار میگیرند. هرچند این فایل ها موقتی هستند و با هربار ریستارت کردن دستگاه از بین میروند، اما اگر ساختار نامناسبی داشته باشند، میتوانند اطلاعات شخصی کاربران را لو بدهند. علاوه بر اینکه نباید PII ها را لاگ کنید، اپلیکیشن باید استفاده از لاگ ها را نیز محدود کند. برای انجام راحت تر این کار، میتوانید از پرچم های debug و کلاس های کاستوم شده Log که قابلیت تعریف سطح دسترسی های مختلف را دارند استفاده کنید.
استفاده از WebView
از آنجایی که WebView از محتوای وب تغذیه میکند و این محتوا میتواند شامل HTML و جاوا اسکریپت باشد، استفاده نادرست از آن ممکن است اشکالات امنیتی رایج وبسایت ها مانند cross-site-scripting (یا همان تزریق جاوا اسکریپت) را برای اپلیکیشن نیز به وجود بیاورد. سیستم عامل اندروید شامل تعدادی از مکانیزم های درونی است که با محدود کردن توانایی های WebView به حداقل کارکردی که اپلیکیشن شما نیاز دارد، حوزه این مشکلات را کاهش میدهد تا امنیت اپ به خطر نیفتد.
اگر اپلیکیشن شما مستقیما از کدهای جاوا اسکریپت در WebView استفاده نمیکند، هیچوقت متد setJavaScriptEnabled را صدا نزنید. تعدادی از نمونه کدهایی که در اینترنت پیدا میشوند، از این متد استفاده میکنند، اما اگر اپلیکیشن شما نیازی به این قابلیت ندارد، آنرا از پروژه حذف کنید. به صورت پیشفرض WebView ها جاوا اسکریپت را اجرا نمیکند، پس امکان ندارد cross-site-scripting اتفاق بیافتد.
در استفاده از متد addJavaScriptInterface با دقت کامل عمل کنید. زیرا این متد به جاوا اسکریپت اجازه میدهد عملکرد هایی که بصورت طبیعی برای اپلیکیشن های اندروید رزرو شده اند را فراخوانی کند. اگر از این متد استفاده میکنید، آن را فقط برای صفحات وبی که همه ورودی هایش قابل اعتماد هستند به کار ببرید. در حالت کلی، ما توصیه میکنیم متد addJavaScriptInterface را فقط برای کدهای جاوا اسکریپت که درون فایل APK اپلیکیشن خودتان قرار دارند استفاده کنید.
اگر اپلیکیشن شما به اطلاعات حساس با استفاده از WebView دسترسی دارد، شما باید از متد clearCache استفاده کنید تا همه فایل هایی که بصورت محلی ذخیره شده اند پاکسازی شوند. همچنین میتوانید از هدر های سمت سرور مانند no-cache استفاده کنید تا مشخص شود اپلیکیشن نباید محتوای خاصی را کش کند.
دستگاه هایی که نسخه های قدیمی تر از اندروید 4.4 (API 19) را اجرا میکنند، یک ورژن از webkit را استفاده میکنند که تعدادی مشکل امنیتی دارند. به عنوان یک راهکار مناسب، اگر اپلیکیشن شما روی این دستگاه ها اجرا میشود، باید مطمئن شوید که آبجکت های WebView تنها محتوای قابل اعتماد را نمایش میدهند. اگر اپلیکیشن شما نیاز دارد محتوای مختلف را از فضای وب نمایش بدهد، باید رندر کننده مخصوصا خودتان را تهیه کنید. با این کار میتوانید با استفاده از patch های امنیتی، همیشه آنها را به روز نگه دارید و امنیت اپ را تامین کنید.
مدیریت کردن Credentials (مدارک)
برای اینکه دست حملات فیشینگ را رو کنید و نگذارید موفق شوند، تعداد درخواست ها برای دریافت مدارک مختلف از کاربر را به حداقل برسانید. به جای این کار از یک توکن احراز هویت استفاده کنید و آن را به روز رسانی نمایید.
سرویس هایی که توسط چندین اپلیکیشن قابل دسترسی هستند، باید توسط AccountManager مورد استفاده قرار بگیرند. اگر امکان داشت، از کلاس AccountManager برای فراخوانی یک سرویس ابری (Cloud-Based) استفاده کنید و پسورد ها را روی دستگاه ذخیره نکنید.
بعد از اینکه با AccountManager به یک Account دسترسی پیدا کردید، CREATOR را قبل از هر مدرکی که میخواهید ارسال کنید به کار ببرید تا مدارک را بصورت اشتباه به دیگر اپلیکیشن ها نفرستید.
اگر مدارک قرار است فقط در اپلیکیشن هایی که خودتان میسازید استفاده شوند، میتوانید اپلیکیشن هایی که به AccountManagre دسترسی دارند را با استفاده از متد checkSignature تایید کنید. اما اگر فقط یک اپلیکیشن از مدارک استفاده میکند، میتوانید با KeyStore ذخیره سازی را انجام بدهید.
استفاده از Cryptography
برای تامین کردن ایزوله سازی داده ها، پشتیبانی از کدگذاری تمام فایل های سیستم و مهیا کردن کانال های ارتباطی ایمن، سیستم عامل اندروید گستره وسیعی از الگوریتم ها برای محافظت از داده ها با استفاده از کریپتوگرافی را مهیا میکند.
در حقیقت، باید بدانید کدام یکی از معماری های کریپتوگرافی جاوا (Java Cryptography Architecture یا JCA) برای تامین امنیت اپلیکیشن شما مناسب تر است. یعنی باید سطح بالا ترین فریم ورک های امنیتی که از قبل در اندروید وجود دارند را با توجه به سناریو خودتان پیاده سازی کنید. اگر پیاده سازی امکان داشت، از Provider هایی که گوگل ارائه داده، با دستوراتی که Google معرفی کرده است استفاده کنید.
برای خواندن و نوشتن فایل های محلی سیستم، میتوانید از کتابخانه Security اندروید استفاده کنید.
اگر میخواهید یک فایل را از یک مکان شناخته شده بصورت ایمن دریافت کنید، یک آدرس HTTPS ساده برای این کار کافی است و نیازی به دانش کریپتوگرافی ندارد. اگر نیاز به یک سوکت امن برای این کار دارید، میتوانید از کلاس HttpsURLConnection یا SSLSocket به جای نوشتن پروتکل خودتان استفاده کنید. اگر از SSLSocket استفاده میکنید، باید بدانید این روش، تاییدیه نام هاست (Host Name) را انجام نمیدهد.
اگر مجبور شدید که پروتکل خودتان را بسازید، نباید الگوریتم های کریپتوگرافی خودتان را پیاده سازی کنید. به جای این کار باید از الگوریتم های کریپتوگرافی که از قبل وجود دارند استفاده کنید. مثلا پیاده سازی AES و RSA که در کلاس Cipher ارائه شده اند نمونه هایی از این روش ها هستند. علاوه بر اینها، باید از بهترین راهکارهایی که در ادامه آوردیم برای امنیت اپ پیروی کنید:
- از AES 256-bit برای موارد تجاری استفاده کنید (اگر ممکن نبود AES 128-bit را به کار ببرید).
- از کلید های عمومی با سایز 224 یا 256 بیت برای کریپتوگرافی های Elliptic Curve یا EC استفاده کنید.
- در جای مناسب از بلاک مود های CBC، CTR یا GCM استفاده کنید.
- از استفاده دوباره IV/counter ها در مود CTR پرهیز کنید. حتما مطمئن شوید آنها به صورت کدگذاری شده رندوم هستند.
وقتی که از encryption استفاده میکنید، با به کار بردن مود های CBC و CTR به همراه توابع زیر، امنیت کامل را برقرار کنید:
- HMAC-SHA1
- HMAC-SHA-256
- HMAC-SHA-512
- GCM mode
یک تولید کننده عدد رندوم ایمن مانند SecureRandom را به کار ببرید. از این اعداد برای مقدار دهی اولیه کلیدهای کریپتوگرافی که توسط KeyGenerator تولید میشوند استفاده کنید. استفاده از کلید هایی که با استفاده از یک تولید کننده عدد رندوم ایمن ساخته نشده اند، میتوانند قدرت الگوریتم را بسیار کاهش بدهند و اپلیکیشن را در معرض حملات آفلاین قرار بدهند.
اگر مجبور هستید یک کلید را برای استفاده های بعدی ذخیره کنید، از یک مکانیزم مانند KeyStore استفاده کنید. این کار مکانیزم هایی را برای ذخیره بلند مدت و بازخوانی دوباره کلید های کریپتوگرافی ارائه میدهد.
استفاده از ارتباطات بین پردازشی
بعضی از اپلیکیشن ها سعی میکنند IPC را با استفاده از تکنیک های قدیمی لینوکس مانند شبکه، سوکت و فایل های به اشتراک گذاشته شده، پیاده سازی کنند. اما برای این کار شما باید از ویژگی های سیستم عامل اندروید مانند Intent، Binder یا Messenger به همراه Service و BroadcastReciever استفاده کنید. مکانیزم IPC اندروید به شما اجازه میدهد هویت همه اپلیکیشن هایی که به IPC شما متصل میشوند را بررسی کنید و برای هر مکانیزم IPC سیاست های امنیتی تعریف کنید.
بسیاری از المان های امنیتی برای همه مکانیزم های IPC در دسترس هستند. اگر مکانیزم IPC شما قرار نیست توسط اپلیکیشن های دیگر استفاده شود، مقدار ویژگی android:exported را برابر false قرار بدهید. این مقدار را باید در فایل Manifest کامپوننت مورد نظر، مثلا برای یک Service، تعریف کنید. این کار برای اپلیکیشن هایی که چندین پردازش را درون یک UID اجرا میکنند مفید است. همچنین اگر بعدا در زمان توسعه اپلیکیشن تصمیم گرفتید که نمیخواهید عملکرد ها را به عنوان IPC برای دیگر اپلیکیشن ها در دسترس قرار بدهید ولی نمیتوانید همه کدها را از اول بنویسید، این کار به شما کمک میکند.
اگر IPC شما برای دیگر اپلیکیشن ها قابل دسترس باشد، میتوانید سیاست های مختلف برای امنیت اپ را با استفاده از المان <permission> تعریف کنید. اگر IPC شما بین اپلیکیشن های خودتان که با استفاده از یک کلید Sign شده اند استفاده میشود، بهتر است از مجوز سطح signature در android:protectionLevel استفاده کنید.
استفاده از Intent ها
برای اکتیویتی ها و BroadcastReciever ها، بهتر است از مکانیرم Intent برای IPC غیر همزمان در اندروید استفاده کنید. بر مبنای نیاز های اپلیکیشن خودتان، میتوانید از متدهای sendBroadcast و sendOrderBroadcast استفاده کنید. همچنین میتوانید یک Intent صریح برای کامپوننت خاصی از یک اپلیکیشن مشخص تعریف کنید و آن را به کار ببرید.
اگر میخواهید برای Bind شدن به یک سرویس از Intent استفاده کنید، مطمئن شوید که اپلیکیشن شما از Intent صریح استفاده میکند. وقتی از Intent های ضمنی استفاده میکنیم تا یک سرویس اجرا شود، مشکلات زیادی برای امنیتی اپ ممکن است به وجود بیاید. زیرا در این صورت شما نمیتوانید مطمئن شوید که کدام سرویس به Intent پاسخ میدهد و کاربر نمیتواند ببیند کدام سرویس شروع شده است. بعد از اندروید نسخه 5.0 (API 21)، اگر متد bindService را با یک Intent ضمنی به کار ببرید، یک Exception در سیستم پرتاب خواهد شد.
این نکته را به یاد داشته باشید که broadcast هایی که درخواست میشوند، میتوانند توسط یک دریافت کننده دیگر مصرف شوند، به همین دلیل ممکن است به دست همه اپلیکیشن ها نرسند. اگر شما میخواهید یک Intent را برای یک دریافت کننده مشخص ارسال کنید، باید از Intent صریح استفاده کنید که نام دریافت کننده درون آن ذکر شده باشد.
ارسال کننده های Intent میتوانند مشخص کنند که دریافت کننده باید Permission خاصی داشته باشد. برای این کار باید یک Permission غیر null با استفاده از متدهای مربوط تعریف شود. در این صورت تنها اپلیکیشن هایی که آن Permission را داشته باشند، Intent را دریافت میکنند. اگر داده هایی که با Broadcast ارسال میکنید شامل اطلاعات حساس هستند، باید مجوز های مخصوص تعریف کنید که اپلیکیشن های مخرب نتوانند به این اطلاعات حساس دسترسی داشته باشند. در این شرایط، میتوانید به جای استفاده از Broadcast بصورت مستقیم دریافت کننده را فراخوانی کنید.
نکته: فیلتر های Intent نباید به عنوان امکانات امنیتی در نظر گرفته بشوند. کامپوننت های مختلف میتوانند با استفاده از Intent ها فراخوانی شوند و ممکن است شامل داده هایی باشند که با فیلتر ها مطابقت نداشته باشند. برای اینکه مطمئن شوید داده ها دارای فرمت درست میباشند و با Reciever، Service یا اکتیویتی فراخوان شده مطابقت دارند. برای این کار باید اعتبار سنجی داده های ورودی را درون دریافت کننده Intent خودتان پیاده سازی کنید.
استفاده از Service ها
یک Service معمولا برای ارائه عملکرد به بقیه اپلیکیشن ها ساخته میشود تا از آن استفاده کنند. هر کلاس Service باید یک المان <service> در فایل منیفست داشته باشد.
بصورت پیشفرض سرویس ها از اپلیکیشن خارج نمیشوند و نمیتوانند توسط دیگر اپلیکیشن ها فراخوانی بشوند. اما اگر هرگونه فیلتر Intent به تعریف سرویس اضافه کنیم، آن ها برای همه اپلیکیشن ها قابل رویت و استفاده میشوند. به همین خاطر بهتر است ویژگی android:exported را به صورت صریح تعریف کنید تا سرویس دقیقا طبق خواسته شما کار کند. سرویس ها میتوانند با استفاده از ویژگی android:permission محافظت بشوند. با این کار، بقیه اپلیکیشن ها باید Permission مورد نظر را در فایل منیفست خود با المان <uses-permission> تعریف کنند تا بتوانند سرویس را شروع و متوقف کرده یا به آن Bind شوند.
نکته: اگر اپلیکیشن شما روی اندروید 5.0 (API 21) به بعد اجرا میشود، باید از JodScheduler برای اجرای سرویس در پس زمینه استفاده کنید.
یک سرویس میتواند IPC Call هایی که برای آن ارسال میشود را با استفاده از Permission محافظت کند. این کار با صدا زدن متد checkCallingPermission قبل از اجرای IPC Call انجام میشود. برای این کار باید Permission ها را در فایل منیفست تعریف کنید.}
مجوز های کلاینت و سرور را با هم اشتباه نگیرید. مطمئن شوید اپلیکیشن صدا زده شده دارای Permission های مناسب میباشد و همچنین اپلیکیشنی که صدا میزند نیز باید Permission های لازم را داشته باشد.
استفاده از اینترفیس های Binder و Messenger
بهتراست از مکانیزم Binder یا Messenger برای IPC هایی به سبک RPC استفاده کنید. این مکانیزم ها اینترفیس های مناسبی را ارائه میدهند که توانایی احراز هویت همزمان در endpoint ها را در صورت امکان را به شما میدهد.
شما باید اپلیکیشن خودتان را به گونه ای طراحی کنید که نیاز به بررس مجوز های اینترفیس نداشته باشد. آبجکت های Binder و Messenger در فایل منیفست اپلیکیشن تعریف نمیشوند، بنابراین شما نمیتوانید Permission ها را مستقیما برای آنها تعریف کنید. این آبجکت ها معمولا Permission های سرویس ها و اکتیویتی هایی که درون آنها پیاده سازی میشوند را به ارث میبرند. اگر شما دارید یک اینترفیس میسازید که نیاز به اهراز هویت یا کنترل دسترسی دارد، باید این کنترل ها را به صورت صریح با کد در اینترفیس های Binder یا Messenger اضافه کنید.
اگر در حال ساخت یک اینترفیس هستید که نیاز به کنترل کننده دسترسی دارد، باید از متد checkCallingPermission برای تایید اینکه صدا زننده دارای Permission های مورد نیاز میباشد یا خیر استفاده کنید. این مسئله به ویژه قبل از دسترسی به یک سرویس از طرف صدا زننده مهم میباشد و باید بررسی شود. زیرا هویت اپلیکیشن شما ممکن است با اینترفیس ها منتقل شود و مشکلاتی برای امنیت اپ به وجود بیاورد. اگر شما اینترفیسی که توسط یک سرویس ارائه شده است را فراخوانی میکنید، صدا زدن متد bindService اگر مجوز های مورد نیاز برای آن سرویس را نداشته باشید، با شکست مواجه میشود. اگر یک اینترفیس که در اپلیکیشن خودتان به صورت محلی ارائه شده است را فراخوانی میکنید، شاید استفاده از متد clearCallingIdentity مفید باشد. این متد مجوز های صدا زننده را از مجوز های اپلیکیشن مخفی میکند تا نیاز های بررسی های امنیتی داخلی را برآورده کند.
استفاده از Broadcast Receiver
آبجکت BroadcastReceiver درخواست های غیر همزمانی که توسط یک Intent ایجاد میشوند را مدیریت میکند.
بصورت پیشفرض، دریافت کننده ها (Receiver ها) در معرض استفاده و فراخوانی توسط اپلیکیشن های دیگر قرار دارند. اگر BroadcastReceiver شما قرار است توسط اپلیکیشن های دیگر استفاده شود، میتوانید با استفاده از المان <receiver> در فایل منیفست پروژه، مجوز های امنیتی مورد نیاز برای دریافت کننده ها را تعریف کنید. این کار اپلیکیشن هایی که مجوز های مناسب ندارند را از ارسال Intent به BraodcastReceiver منع میکند.
بارگذاری پویای کد
ما به هیچ وجه توصیه نمیکنیم که از بیرون فایل APK اپلیکیشن، اقدام به وارد کردن کد بکنید. با این کار اپلیکیشن شدیدا در معرض خطرهایی مانند تزریق یا دستکاری کد قرار میگیرد که امنیت اپ را بسیار کاهش میدهد. همچنین ممکن است برای کنترل ورژن یا تست اپلیکیشن با پیچیدگی های زیادی روبرو شوید. علاوه بر اینها، با این کار رفتار اپلیکیشن غیر قابل پیش بینی میشود و به همین دلیل در بعضی محیط ها فعالیت آن ممنوع خواهد شد.
اگر اپلیکیشن شما کدها را بصورت پویا بارگذاری میکند، مهمترین نکته ای که باید در ذهن داشته باشید این است که کدهایی که بصورت پویا در اپلیکیشن بارگذاری میشوند، با همان مجوز های امنیتی موجود برای فایل APK اپلیکیشن اجرا خواهند شد. کاربر بر اساس هویت شما تصمیم به نصب اپلیکیشن میگیرد و انتظار دارد شما همه کدهایی که درون اپلیکیشن اجرا میشوند را مهیا کنید، حتی کدهایی که بصورت پویا بارگذاری میشوند.
بزرگترین ریسک امنیتی که درباره کدهای بارگذاری شده پویا وجود دارد این است که این کدها باید از منابع قابل اعتماد به دست اپلیکیشن برسند. اگر ماژول ها مستقیما درون اپلیکیشن شما وجود داشته باشند، بقیه اپلیکیشن ها نمیتوانند آنها را دستکاری کنند. این مسئله برای کدهایی که بصورت لایبرری بومی در اپلیکیشن حضور دارند و همچنین برای کلاس هایی که با استفاده از DexCalssLoader بارگذاری میشوند صدق میکند.
بسیاری از اپلیکیشن ها سعی میکنند کدهایی را بارگذاری کنند که از محل های غیر ایمن مانند دانلود از شبکه هایی که پروتکل های رمزگذاری شده ندارند و یا محل هایی که برای همه قابل ویرایش هستند مانند حافظه های خارجی آمده اند. این مکان ها به دیگران اجازه میدهند که داده ها را در زمان ارسال به اپلیکیشن شما دستکاری کرده یا به اپلیکیشن های دیگر موجود درون دستگاه کاربر اجازه میدهد که بتوانند کدها را تغییر بدهند.
امنیت در ماشین مجازی
Dalvik ماشین مجازی (VM) اندروید است. با اینکه Dalvik بصورت اختصاصی برای اندروید نوشته شده است، اما ملاحظات امنیتی که در ماشین های مجازی دیگر وجود داشتند نیز برای آن لحاظ شده اند. در حقیقت، شما نباید نگران مشکلات امنیتی ماشین مجازی باشید. اپلیکیشن شما در یک محیط ایمن و ایزوله شده (Sandbox) اجرا میشود. به همین دلیل بقیه پردازش های سیستم نمیتوانند به کدها و داده های خصوصی شما دسترسی داشته باشند.
این نوشته روی حوزه هایی که مخصوص اندروید هستند یا با محیط دیگر ماشین های مجازی تفاوت دارند تمرکز دارد. اما برای توسعه دهنده هایی که تجربه کدنویسی با ماشین مجازی در دیگر محیط ها را داشته اند، دو مشکل کلی وجود دارد که شاید با نوشتن اپلیکیشن برای اندروید تفاوت داشته باشند:
تعدادی از ماشین های مجازی مانند JVM یا .NET runtime مانند یک مرز امنیتی عمل کرده و کدها را از توانایی های سیستم عاملی که روی آن اجرا میشوند، ایزوله میکنند. اما در اندروید، Dalvik یک مرز امنیتی نیست. Sandbox اپلیکیشن ها در همان سطح سیستم عامل پیاده سازی شده است. پس Dalvik میتواند با کدهای بومی موجود در همان اپلیکیشن، بدون هیچ قید امنیتی، کار کند.
از آنجایی که حافظه روی گوشی موبایل محدودیت دارد، توسعه دهندگان معمولا اپلیکیشن های ماژولار میسازند و از بارگذاری پویای کلاس استفاده میکنند. برای انجام این کار، باید هر دو منبعی که منطق اپلیکیشن شما از آن می آید و همچنین مکانی که آنها را بصورت محلی ذخیره میکنید را در نظر بگیرید. هیچوقت از بارگذاری پویای کلاس از منابعی که تایید نشده اند، مانند شبکه های کدگذاری نشده و حافظه خارجی، استفاده نکنید. زیرا این کدها ممکن است رفتار های خرابکارانه داشته باشند.
امنیت در کدهای بومی
در حالت عادی شما باید از Android SDK برای توسعه اپلیکیشن های بومی استفاده کنید، نه از کیت توسعه بومی اندروید یا Android NDK. اپلیکیشن هایی که با کدهای بومی ساخته میشوند پیچیده تر هستند، انعطاف کمتری دارند و معمولا بیشتر شامل ارور های مربوط به مموری مانند buffer overflow میشوند.
اندروید با استفاده از هسته لینوکس ساخته شده است و اگر با کدهای بومی کار میکنید، آشنایی با بهترین راهکار های توسعه در لینوکس میتواند بسیار برای شما مفید باشد. در این نوشته درباره نکته های امنیتی لینوکس صحبت نمیکنیم، ولی شما میتوانید درباره آنها جستجو کنید تا بهتر بتوانید امنیت اپ خودتان را تامین کنید.
یکی از تفاوت های مهم بین اندروید و بیشتر محیط های لینوکسی، Application Sandbox است. در سیستم عامل اندروید همه اپلیکیشن ها، حتی آنهایی که با کدهای بومی نوشته شده اند، درون Sandbox اجرا میشوند. یکی از ابتدایی ترین موارد، برای توسعه دهنده هایی که تجربه کار با لینوکس را دارند این است که در اندروید، به هر اپلیکیشن یک UID یکتا با مجوزهای بسیار محدود داده میشود. برای توسعه بومی باید با مجوز های اپلیکیشن و دیدکلی به سیستم امنیتی اندروید آشنا باشید.
منابع بیشتر برای مطالعه
میتوانید از منابع زیر برای مطالعه بیشتر درباره امنیت اپ اندروید استفاده کنید:
