مروری بر حملات برنامه های اندروید

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

معرفی برنامه های اندروید

مدل‌سازی تهدید برای برنامه‌های کاربردی موبایل

مروری کلی بر 10 آسیب‌پذیری برتر موبایل OWASP

معرفی ابزارهای خودکارسازی برای ارزیابی برنامه‌های کاربردی اندروید

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

معرفی برنامه‌های کاربردی اندروید

برنامه‌های کاربردی اندروید بر اساس نحوه توسعه آنها به سه نوع تقسیم می‌شوند:

برنامه‌های کاربردی مبتنی بر وب

برنامه‌های کاربردی بومی (native)

برنامه‌های کاربردی ترکیبی (hybrid)

برنامه‌های کاربردی مبتنی بر وب

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

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

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

برنامه‌های کاربردی ترکیبی

برنامه‌های کاربردی ترکیبی سعی می‌کنند از هر دو برنامه کاربردی بومی و وب بیشترین استفاده را ببرند، و مانند یک برنامه کاربردی بومی برروی دستگاه اجرا می‌شوند و با تکنولوژی‌های وب (HTML5، CSS و جاوا اسکریپت) نوشته می‌شوند. برنامه‌های کاربردی ترکیبی در یک کانتینر بومی اجرا می‌شوند و از موتور مرورگر دستگاه (و نه مرورگر) برای رندر HTML و پردازش جاوااسکریپت به طور محلی، استفاده می‌کنند. لایه انتزاعی وب به بومی اجازه دسترسی به قابلیت‌های دستگاه را می‌دهد که در برنامه‌های کاربردی مبتنی بر وب موبایل مانند شتاب سنج، دوربین و حافظه محلی قابل دسترسی نیست. معمولا این نوع برنامه‌های کاربردی با استفاده از چارچوب‌هایی نظیر PhoneGap، React Native و غیره توسعه داده می‌شوند. با این حال، وجود سازمان‌هایی که کانتینرهای خود را ایجاد می‌کنند، نیز غیر‌معمول نیست.

درک سطح حمله برنامه کاربردی

هنگامی که یک برنامه کاربردی توسعه داده می‌شود، باید از کنترل‌های امنیتی در هر لایه از معماری برنامه کاربردی استفاده کرد.

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

برنامه‌های کاربردی موبایل مانند شبکه‌های اجتماعی، بانکداری و برنامه‌های سرگرمی، شامل عملکردهای متنوعی هستند که نیاز به ارتباط اینترنتی دارد و بنابراین بسیاری از برنامه‌های کاربردی موبایل امروزی، همانطوریکه در نمودار زیر نشان داده شده است، دارای معماری مشتری-سرور معمولی می‌باشند. پس از درک سطوح حمله این نوع برنامه‌های کاربردی، لازم است همه احتمالات برنامه کاربردی که شامل آسیب‌پذیری‌های مرتبط با برنامه کاربردی سرویس‌گیرنده، Backend API ، سرور، و پایگاه‌داده است را در نظر گرفت. نقطه ورود هر یک از این مکان‌ها ممکن است تهدیدی برای کل برنامه کاربردی یا داده‌های آن باشد. برای مثال، فرض کنید که ما یک برنامه کاربردی اندروید داریم که با استفاده از API Backend با سرور ارتباط برقرار می‌کند، که به نوبه خود با پایگاه داده در تعامل است:

توصیه می‌شود که در هنگام توسعه نرم‌افزار، از فرآیند Secure SDLC تبعیت شود. بسیاری از سازمان‌ها، این روش از SDLC را برای اجرای امنیت در هر مرحله از فرآیند چرخه حیات توسعه نرم‌افزار مدنظر قرار می‌دهند. چرخه حیات توسعه نرم‌افزار (SDLC)امن، روشی برای کمک به سازمان‌ها به منظور ایجاد امنیت در محصولات‌شان، از ابتدای فرآیند SDLC می‌باشد. پذیرش SDLC، با کاهش تلاش‌های لازم برای حل مسائل در طی چرخه‌های تعمیر و نگهداری، بهره‌وری را افزایش می‌دهد.

چنانچه می‌توان در نمودار زیر که از سند فرآیند SDLC Microsoft گرفته شده، مشاهده کرد، هر مرحله از SDLC شامل حداقل یک فعالیت امنیتی است که به امنیت برنامه کاربردی کمک می‌کند. هر سازمانی در تعبیه امنیت در SDLC و بلوغ، متفاوت است. با این حال، موارد زیر می‌تواند شروع خوبی برای سازمان‌هایی باشد که به پذیرش این روش می‌اندیشند:

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

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

تحلیل پویا:   تحلیل پویا در مرحله بازبینی فرآیند SDLC انجام می‌شود. تحلیل پویا، روشی برای پیدا کردن مسائل برنامه کاربردی در حین اجرا می‌باشد که می‌تواند به سازمان‌ها در شناخت وضعیت امنیتی برنامه‌ها کاربردیشان قبل از استقرار کمک کند.

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

تهدیدات سمت مشتری

داده های مانای برنامه: برنامه‌های کاربردی موبایل که با پس‌زمینه (backend)ارتباط برقرار می‌کنند، با احتمال بالایی در معرض حملاتی هستند که داده‌های در حال انتقال را هدف قرار می‌دهند. به طور معمول کاربران نهایی به شبکه های عمومی موجود در کافی‌شاپ‌ها و فرودگاه‌ها می‌پیوندندکه ممکن است مهاجم بتواند از طریق ابزارهایی مانند پروکسی burp، پروکسی MITM، پروکسی SSL MitM و امثال آنها استراق سمع کند. با معرفی برنامه‌های کاربردی تلفن هوشمند، بهره‌برداری از چنین حملاتی بسیار آسان می‌شود زیرا هر جا که می‌رویم، موبایل‌‌ها را با خود به همراه داریم.

داده های در حال انتقال برنامه:برنامه های موبایل که با backend ارتباط برقرار می‌کنند، با احتمال بالایی در معرض حملاتی هستند که داده های در حال انتقال را هدف قرار می دهند. به طور معمول کاربران نهایی به شبکه های عمومی موجود در کافی شاپ ها و فرودگاه ها می‌پیوندندکه ممکن است مهاجم بتواند از طریق ابزارهایی مانند پروکسی burp، پروکسی MITM، پروکسی SSL MitM و امثال آنها استراق سمع کند. با معرفی برنامه های تلفن هوشمند، بهره برداری از چنین حملاتی بسیار آسان می شود زیرا تلفن های همراه هر جا که می‌رویم ما را دنبال می‌کنند.

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

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

مسائل خاصِ پلتفرم: هنگام طراحی یک مدل تهدید برای برنامه‌های کاربردی موبایل، مهم است که تهدیدات مرتبط با پلتفرمی که این برنامه کاربردی می‌خواهد برروی آن اجرا شود مورد توجه قرار گیرد. به عنوان مثال برای اندروید، برنامه‌های کاربردی بومی که برای پلتفرم اندروید توسعه یافته‌اند، می‌توانند به راحتی مهندسی معکوس شده و کد منبع جاوا می‌تواند به آسانی مشاهده شود. این امر به مهاجم اجازه مشاهده کد منبع و همچنین هر گونه دسترسی به اطلاعات حساس هاردکد شده -را می‌دهد. همچنین، امکان تغییر کد در برنامه کاربردی و کامپایل مجدد آن و سپس توزیع برنامه کاربردی در بازارهای شخص ثالث وجود دارد. اگر برنامه کاربردی ذاتا حساس و یا برنامه‌ای از نوع پرداخت پول باشد، بررسی یکپارچگی برنامه کاربردی باید مدنظر قرار گیرد. اگرچه مسائل ذکر شده در بالا در یک پلتفرم همانند iOS تاثیر نسبتا کمتری دارند، اما در صورتی که دستگاه jail-broken باشد، مسائل مربوط به خود را دارد.

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

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

اعتبارسنجی/هویت‌سنجی: هنگام توسعه API های پس‌زمینه، ایجاد یک مکانیزم اعتبارسنجی سفارشی رایج است. بنابراین ممکن است آسیب‌پذیری‌های مرتبط با هویت‌سنجی یا اعتبارسنجی وجود داشته باشد.

مدیریت نشست:مدیریت نشست در پلتفرم‌های موبایل معمولا با استفاده از یک توکن هویت‌سنجی (authentication) انجام می‌شود. هنگامی که کاربر برای اولین بار وارد سیستم می‌شود، به او یک توکن هویت‌سنجی داده می‌شود که برای ادامه‌ نشست استفاده می‌شود. اگر این توکن هویت‌سنجی تا زمان از بین رفتن نشست به درستی محافظت نشود، ممکن است منجر به حمله گردد. از بین بردن نشست کاربر در سمت سرویس‌گیرنده، نه در سرور، مشکل دیگری است که در برنامه‌های کاربردی موبایل دیده می‌شود.

اعتبارسنجی ورودی: اعتبارسنجی ورودی یک مسئله شناخته شده و رایج است که در برنامه‌های کاربردی مشاهده می‌کنیم. اگر هیچ کنترلی برروی اعتبارسنجی ورودی صورت نگیرد، ممکن است آسیب‌پذیری‌های SQL injection، Command Injection و Cross Site Scripting وجود داشته باشند.

مدیریت نامناسب خطا: خطاها برای مهاجمان جذاب هستند. اگر مدیریت خطا به درستی صورت نگیرد و API، خطاهای پایگاه داده / سرور را بطور خاص برای درخواست ایجاد شده بفرستد، می‌توان حملات را با استفاده از آن خطاها انجام داد.

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

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

دستورالعمل‌هایی برای تست و ایمن‌سازی برنامه‌های موبایل

سازمان‌های متعددی هستند که دستورالعمل‌هایی را برای تست و ایمن سازی برنامه‌های موبایل ارائه می‌دهند. رایج‌ترین آنها عبارتند از OWASP Mobile Top10 و Veracode Mobile App Top10. علاوه بر این، دستورالعمل‌هایی از خود گوگل نیز درباره نحوه ایمن‌سازی برنامه‌های کاربردی اندروید با ارائه مثال هایی از آنچه انجام نمی‌شود، وجود دارد. داشتن اطلاعات در مورد این دستورالعمل‌ها مهم است تا بدانید چه چیزی در طول آزمون نفوذ باید جستجو شود.
حال نگاه کوتاهی به آسیب‌پذیری‌های OWASP Mobile Top10 خواهیم داشت.

ریسک‌های OWASP Top10 Mobile

نمودار زیر ریسک‌های OWASP Top10 Mobile را نشان می‌دهد که 10 آسیب‌پذیری برنامه - کاربردی موبایل را که در سال 2014 منتشر شده، لیست کرده است.

در زیر 10 آسیب‌پذیری برتر بیان شده و در بخش‌های زیر نگاهی عمیق تر به هر یک از این آسیب‌پذیری‌ها خواهیم داشت.

M1: کنترل‌های ضعیف سمت سرور

M2: ذخیره ناامن داده ها

M3: حفاظت ناکافی لایه انتقال

M4: نشتی ناخواسته داده ها

M5: هویت‌سنجی و اعتبارسنجی ضعیف

M6: رمزنگاری شکسته

M7: تزریق سمت مشتری

M8: تصمیمات امنیتی از طریق ورودی‌های نامطمئن

M9: مدیریت نامناسب نشست

M10: فقدان محافظهای باینری

M1: کنترل‌های ضعیف سمت سرور

کنترل‌های ضعیف سمت سرور به مساله حملات برروی پس‌زمینه برنامه کاربردی می‌پردازند. امروزه اکثر برنامه‌ها از اتصال به اینترنت استفاده می‌کنند و با استفاده از API های REST یا SOAP با سرورهای پس‌زمینه ارتباط برقرار می‌کنند. اصول امنیتی مرتبط با وب سرورها و برنامه‌های کاربردی وب یکسان است، چرا که صرفا پیش‌زمینه برنامه (سرویس‌گیرنده موبایل) فرق می‌کند و پس‌زمینه همچنان یکسان است. مسیرهای معمول حمله عبارتند از: شناسایی نقاط ورود در API های فاقد محافظ و گیج کردن آن‌ها برای آسیب‌پذیری‌های مختلف، بهره‌برداری از سرورهای بد پیکربندی شده و غیره. تقریبا تمام آسیب‌پذیری‌های OWASP top 10 به این بخش اعمال می‌شود.

M2: ذخیره ناامن داده ها

توسعه دهندگان فرض می‌کنند که اطلاعات ذخیره شده در سیستم فایل یک دستگاه توسط مهاجمان قابل دسترسی نیست. با این فرض، توسعه دهندگان اغلب داده‌های حساس مانند نام‌های کاربری، توکن‌های هویت‌سنجی، گذرواژه‌ها، PINها و اطلاعات شخصی مانند DOB و آدرس‌ها را در سیستم فایل یک دستگاه با استفاده از مفاهیمی مانند تنظیمات مشترک یا پایگاه‌های SQLite ذخیره می‌کنند. چندین روش برای دسترسی به این داده‌ها که به صورت محلی بر روی یک دستگاه ذخیره می‌شوند وجود دارد. از جمله تکنیک‌های رایج، root کردن دستگاه و دسترسی به داده‌ها، استفاده از حملات مبتنی بر پشتیبان و غیره است.

M3: حفاظت ناکافی لایه انتقال

همانطوریکه در نمودار قبلی می‌توان مشاهده کرد، حفاظت ناکافی لایه انتقال در مکان سوم قرار دارد. همانند برنامه‌های کاربردی وب، برنامه‌های کاربردی موبایل ممکن است اطلاعات حساس را از طریق شبکه‌های ناامن انتقال دهند که این امر ممکن است به حملات جدی منجر شود. این مساله در کافی‌شاپ‌ها و فرودگاه‌ها برای دسترسی به Wi-Fi های رایگان بسیار رایج است که در آن مهاجمان مخرب می‌توانند حملات MITM را برای سرقت اطلاعات حساس از کاربران در شبکه انجام دهند.
هنگام انجام تست نفوذ برروی برنامه‌های کاربردی موبایل، ممکن است سناریوهایی وجود داشته باشد که در آن برنامه کاربردی، توکن‌های نشست یا اعتبارها - را بر روی شبکه انتقال دهد. بنابراین، همیشه یک ایده خوب - تحلیل ترافیک برنامه کاربردی است تا ببینیم که آیا اطلاعات حساس برروی شبکه انتقال می‌یابد یا خیر. یک سناریوی مهم دیگر وجود دارد که اکثر برنامه‌های کاربردی آسیب‌پذیر هستند. اگر یک برنامه کاربردی، اعتبارسنجی را بر روی HTTPS انجام داده و کوکی‌های اعتبارسنجی را بر روی HTTP ارسال کند، برنامه کاربردی آسیب‌پذیر است، زیرا مهاجم به راحتی می‌تواند کوکی‌های اعتبارسنجی منتقل شده بر روی HTTP را دریافت کرده و این کوکی‌ها - نام کاربری و رمز عبور قوی برای ورود به برنامه کاربردی هستند. همچنین عدم تأیید اعتبار و مذاکره ضعیف با handshake -، مشکلات رایج در رابطه با امنیت لایه انتقال است.

M4: نشتی ناخواسته داده ها

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

نشتی ارائه دهندگان محتوا

کپی / چسباندن کش بافر

ورود به سیستم

کش کردن URL

اشیاء کوکی مرورگر

تحلیل داده‌های ارسال شده به اشخاص ثالث

M5: هویت‌سنجی و اعتبارسنجی ضعیف

برنامه‌های کاربردی موبایل و همچنین دستگاه‌ها، فاکتورهای قابلیت استفاده متفاوتی دارند، در مقایسه با آنچه که در برنامه‌های کاربردی وب سنتی و لپ‌تاپ‌ها وجود دارد. به دلیل فاکتور فرم ورودی دستگاه موبایل، اغلب لازم است که PIN ها و گذرواژه های کوتاه داشته باشید. به علت نیازمندی‌های دسترسی‌پذیری، نیازمندی‌های هویت‌سنجی برای برنامه‌های کاربردی موبایل می‌تواند کاملا متفاوت با شِماهای هویت‌سنجی وب سنتی باشد. چنانچه هیچ کنترلی برای جلوگیری از چنین حملاتی اعمال نشود، برای یک حمله کننده بسیار آسان خواهد بود تا این PIN های کوتاه را از طریق brute force در برنامه کاربردی پیدا کند. می‌توانیم شِماهای هویت‌سنجی ضعیف را، با تلاش برای دسترسی بیشتر به توابع برنامه کاربردی با ایجاد درخواست‌های مخرب و ارسال آن به سرور و بررسی اینکه آیا این درخواست‌ها پاسخ داده می‌شوند یا نه، تست کنیم.

M6: رمزنگاری شکسته

حملات رمزنگاری زمانی رخ می‌دهند که توسعه دهنده برنامه کاربردی می‌خواهد از رمزگذاری در برنامه کاربردی خود استفاده کند. رمزنگاری شکسته در برنامه‌های کاربردی اندروید می‌تواند به دلایل مختلف روی دهد. دو دلیل عمده، چنانچه در پروژه OWASP Mobile Top 10 ذکر شده است، عبارتند از:

استفاده از یک الگوریتم ضعیف برای رمزگذاری / رمزگشایی:  شامل استفاده از الگوریتم‌هایی با نقاط ضعف قابل توجه است و یا در غیر این صورت برای نیازمندی‌های امنیتی مدرن مانند DES، DES3 و غیره مناسب نیستند.

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

M7: تزریق سمت مشتری

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

تزریق در WebViews

تزریق سنتی SQL در دستورات خام SQL با استفاده از پایگاه‌داده SQLite

تزریق SQL در ارائه دهندگان محتوا

پیمایش مسیر در ارائه دهندگان محتوا

M8: تصمیمات امنیتی توسط ورودی‌های نامطمئن

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

M9: مدیریت نامناسب نشست

برنامه‌های کاربردی موبایل از پروتکل‌هایی مانند SOAP یا REST که stateless هستند، برای اتصال به سرویس‌ها استفاده می‌کنند. هنگامی که یک برنامه کاربردی سرویس‌گیرنده موبایل با این پروتکل‌ها استفاده می‌شود، سرویس‌گیرنده پس از هویت‌سنجی یک توکن از سرور دریافت می‌کند. توکن تولید شده توسط سرور در طی نشست کاربر استفاده می‌شود. مدیریت نامناسب نشست OWASP به حمله و تأمین امنیت این نشست‌ها می‌پردازد. یک مشکل رایج که اغلب در برنامه‌های کاربردی موبایل مشاهده می‌شود، توکن نامعتبر در سمت مشتری و نه در سمت سرور است. معمولا، توکن دریافت شده توسط برنامه کاربردی با استفاده از تنظیمات مشترک یا پایگاه داده‌های SQLite در سیستم فایل سرویس‌گیرنده قرار می‌گیرد. یک کاربر مخرب که به این توکن‌‌ها دسترسی دارد، تا زمانیکه توکن در سمت سرور نامعتبر نشده باشد، می‌تواند از آنها استفاده کند. دیگر سناریوهای ممکن عبارتست از مدت زمان اعتبار نشست، ایجاد توکن ضعیف و توکن منقضی شده.

M10: فقدان محافظهای دودویی

مهندسی معکوس یکی از رایج‌ترین مشکلات موجود در اکثر برنامه‌های کاربردی اندروید است. یکی از اولین گام‌های مهاجم هنگامی که یک برنامه کاربردی باینری را دریافت می‌کند،decompile یا disassemble کردن آن است. این امر به مهاجم اجازه می دهد تا موارد پنهان هاردکد شده را مشاهده کند، آسیب پذیری‌ها را پیدا نموده و حتی عملکرد برنامه را با بسته‌بندی مجدد برنامه‌های کاربردی disassemble شده تغییر دهد. اگرچه پنهان‌سازی(obfuscating)کد منبع کار سختی نیست، اما به نظر نمی‌رسد که اکثریت برنامه‌های کاربردی این کار را انجام دهند. هنگامی که کد پنهان‌سازی نشده است، تنها نیاز مهاجمین یک ابزار خوب مانند apktool یا dex2jar برای انجام کار است. برخی از برنامه‌های کاربردی، دستگاه های root شده را بررسی می‌کنند که می‌توان این بررسی‌ها را از طریق معکوس کردن برنامه یا با دستکاری جریان برنامه کاربردی با به دام انداختن آن، دور زد.

ابزارهای خودکارسازی

ابزارهای خودکارسازی اغلب مدت زمان انجام تست نفوذ را کاهش می‌دهند. در زیر برخی از رایج‌ترین ابزارهای خودکارسازی که برای ارزیابی برنامه‌های کاربردی اندروید در دسترس هستند، آمده است:

Drozer و Quark دو ابزار مختلف هستند که ممکن است در زمان ارزیابی برنامه کاربردی اندروید مفید باشند.

شرکت مهندس پیشگان آزمون افزار یاس، ابزارهای پیشرفته زیر را در حوزه تست نفوذ اندروید ارائه می دهد:

Jtest

Checkmarx

WebInspect

نویسنده : شرکت مهندس پیشگان آزمون افزار یاس