۱. محافظت دودویی

شناسایی Root/‎ Jailbreak جیلبریک نیمه‌کاره. Root کردن یا جیلبریک یک دستگاه به معنی دور زدن مدل‌های حفاظتی و رمزنگاری در آن سیستم است. زمانی که دستگاه در معرض خطر قرار می‌گیرد، هر نوع کد مخربی می‌تواند بر روی دستگاه اجرا شود که می‌تواند به میزان قابل ملاحظه‌ای رفتارهای مورد انتظار منطق برنامه را تغییر دهد. ابزارهای ترمیم و بازیابی داده‌ها عموماً بر روی دستگاه‌های root شده نیز اجرا می‌شوند.

راهکار:

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

۲.کمبود محافظت کافی در لایه انتقال

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

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

راهکار:

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

۳. نشت اطلاعات | نسخه سرور

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

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

راهکار:

اطلاعات غیر ضروری‌ که ممکن است داده‌های بیشتری در خصوص شبکه شما به حمله کننده بدهد را از پاسخ‌های سرور حذف کنید.

۴. نشت اطلاعات | داده‌های حساس

این مورد به لحاظ اطلاعاتی، مشابه نشتی اطلاعات نسخه سرور است که در شماره ۳ بیان شد، اما موارد نشتی بیشتری درون برنامه، بین برنامه‌ای و غیره را نیز در بر می‌گیرد.

راهکار:

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

۵. احراز هویت | اعتبار سنجی ناکافی

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

روش‌های احراز هویت باید مرز و حدودی را برای آنچه کاربر، سرویس یا برنامه اجازه انجام آن را دارد تعیین کند. تائید اعتبار کاربر برای یک وب‌سایت، لزوماً به این معنی نیست که آن کاربر دسترسی کامل به کل محتوا  و قابلیت‌های عملیاتی آن برنامه را دارد.

راهکار:

هر زمان که امکان‌پذیر بود یک مدل فریم ورک معتبر احراز هویت را اعمال کنید که هر چه بیشتر از فایل‌های پیکربندی مبتنی بر قانون به جای بررسی‌های احراز هویت/ اعتبارسنجی کد نویسی شده پیچیده استفاده کرده باشد.

۶. رمزنگاری | اعتبار سنجی نامناسب گواهی

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

راهکار:

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

۷. حمله جست و جوی فراگیر | سرشماری کاربر

راه‌های متعددی پیش روی حمله کننده قرار دارد که به وسیله آن می‌تواند تعیین کند که آیا یک کاربر در سیستم وجود دارد یا خیر؛ حمله جست و جوی فراگیر روشی است که با امتحان کردن تعداد زیادی از مقادیر ممکن، مقداری ناشناخته را تعیین می‌کند. مزیتی که این روش از آن بهره می‌برد این است که درجه تصادفی بودن مقادیر کمتر از آن چیزی است که به نظر می‌رسد. برای مثال، با وجود این که گذرواژه‌های ۸ حرفی عددی و الفبایی ۲/۸ تریلیون حالت ممکن دارند، بسیاری از افراد گذرواژه‌هایشان را از زیرمجموعه کوچک‌تری از لغات و واژگان رایج انتخاب می‌کنند.

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

اگر شماره شناسه کاربر (ID) به شیوه‌ای قابل پیش‌بینی و به صورت متوالی تولید شده باشد (XX102017, XXX112017 و غیره) حمله کننده می‌تواند با شمارش افزایشی لیست، شماره شناسه کاربران را بیابد.پ

راهکار:

نقطه آسیب‌رسان برای شناسایی شماره شناسه کاربر، اغلب در توابع عملیاتی ذیل رخ می‌دهد: ورود، ثبت‌نام یا فراموشی گذرواژه. برنامه می‌بایست معتبر بودن نام کاربری را نشان ندهد. عکس‌العمل برنامه در برخورد با ورودی‌های معتبر یا نامعتبر باید کاملاً یکسان باشد.

به‌عنوان مثال یک واکنش مناسب به جای ” متأسفانه، گذرواژه شما نامعتبر است” می‌تواند این باشد:” نام کاربری یا گذرواژه شما صحیح نیست. لطفاً مجدداً امتحان کنید.

۸. انقضای نشست نیمه‌کاره

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

راهکار:

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

۹. نشت اطلاعات | حافظه کش برنامه

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

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

راهکار:

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

۱۰. حفاظت دودوئی | ایجاد ابهام در کد به صورت نیمه‌کاره

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

راهکار:

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