ایمن‌سازی ارتباطات بک‌اند اپ موبایل چگونه است؟

امنیت اپلیکیشن‌های موبایل: راهنمای کامل جلوگیری از دستکاری و حملات MitM

اپلیکیشن‌های موبایل به اندازهٔ اپلیکیشن‌های وب امن هستند، اما در معرض خطر بیشتری قرار دارند زیرا می‌توانند در محیط مهاجم نیز اجرا شوند. بنابراین اعتماد کامل به آن‌ها اشتباه است. هیچ روش دفاعی واحدی تضمین‌کنندهٔ جلوگیری از بازیابی اسرار، دستکاری اپلیکیشن و حملات man-in-the-middle (MitM) نیست.

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

چرا نمی‌توان به درخواست‌های اپلیکیشن اعتماد کرد

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

دستکاری اپلیکیشن، جایی که اپلیکیشن‌های تغییر یافته روی هر دستگاهی (حتی غیرروت) نصب می‌شوند، اجازهٔ دستکاری ترافیک و رفتار زمان اجرا را می‌دهد. علاوه بر این، حملات MitM که در وب رایج هستند، به مهاجمان اجازه می‌دهد درخواست‌ها را حین انتقال رهگیری و تغییر دهند، حتی روی TLS، با استفاده از گواهی‌نامه‌های root سفارشی.

ما به طور مکرر حملات سمت سرور مانند بازیابی اسرار (استخراج API key برای دسترسی غیرمجاز) و MitM همراه با دستکاری درخواست‌ها (رهگیری و تغییر ارتباط اپلیکیشن و سرور) را مشاهده می‌کنیم. مهاجمان همچنین با اتوماسیون تعاملات اپلیکیشن روی امولاتورها/دستگاه‌ها یا مهندسی معکوس پروتکل‌های API، فارم‌های بات ایجاد می‌کنند.

این حملات دیگر تنها نظریه نیستند. ما مشاهده کرده‌ایم که APIهایی با دسترسی نامحدود، داده‌های موقعیت کاربر را فاش کرده‌اند یا مهاجمان با مهندسی معکوس کلاینت‌های موبایل، حملات credential stuffing را خودکار کرده‌اند. به عنوان مثال، یک اپلیکیشن محبوب فیتنس داده‌های موقعیت کاربران را به دلیل پاسخ‌های API بیش از حد آزاد فاش کرد. در موردی دیگر، مهاجمان اپلیکیشن‌ها را مهندسی معکوس کردند تا endpointهای خصوصی را شناسایی و حملات credential-stuffing اجرا کنند.

چگونه از بازیابی اسرار جلوگیری کنیم

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

اگر اپلیکیشن شما واقعاً نیاز به استفاده از یک راز دارد، بهتر است آن را دینامیک از سرور backend در زمان اجرا دریافت کنید، مانند بعد از احراز هویت کاربر، تا استخراج استاتیک از باینری اپلیکیشن جلوگیری شود. اگرچه بهتر است، ذخیره محلی روی دستگاه‌های روت/جیلبریک همچنان یک ریسک است. می‌توانید با استفاده از مکانیزم‌های ذخیره امن که TEE یا SE API را بهره می‌برند، این ریسک را کاهش دهید.

Runtime application self-protection (RASP) نیز می‌تواند مهاجمان را که از hooking یا تحلیل دینامیک برای استخراج اسرار استفاده می‌کنند، شناسایی و مسدود کند. مزیت مهم بازیابی دینامیک، امکان به‌روزرسانی اسرار در صورت افشا بدون نیاز به بروزرسانی اپلیکیشن است، که مدیریت گردش اسرار و محدود کردن تأثیر افشا را آسان می‌کند.

اگر یک راز باید همیشه در دسترس باشد و نمی‌توان آن را دینامیک دریافت کرد، hardcoding کم‌امن‌ترین گزینه است و باید فرض شود که افشا شده است. برای کاهش ریسک، از مبهم سازی و کد گذاری، RASP ضد-hooking، محافظت ضد MitM و چرخش منظم اسرار استفاده کنید.

چگونه MitM و دستکاری درخواست را جلوگیری کنیم

حملات MitM ساده و مؤثر هستند، تنها کافیست مهاجم یک پراکسی نصب کند و گواهی آن را به trust store دستگاه اضافه کند. این امکان رهگیری، رمزگشایی و تغییر ترافیک TLS را فراهم می‌کند و ساختار و رفتار درخواست‌های اپلیکیشن را فاش می‌کند. یک دفاع چندلایه ضروری است، زیرا هیچ روش واحدی کامل نیست.

۱. Certificate Pinning

یک تکنیک کلیدی، certificate pinning است که اطمینان می‌دهد اپلیکیشن تنها گواهی‌های امضا شده توسط CAهای شناخته شده یا کلیدهای عمومی مشخص را می‌پذیرد. بنابراین اپلیکیشن، اتصال از گواهی پراکسی MitM را که در لیست مورد تایید نیست، رد می‌کند.

با این حال، certificate pinning می‌تواند با ابزارهای عمومی دور زده شود مگر آنکه با RASP ترکیب شود. استفاده از ضد hook و ضد tampering توصیه می‌شود. توجه داشته باشید که تغییر گواهی پین شده باعث می‌شود اپلیکیشن‌های قبلی قادر به اتصال به backend نباشند.

۲. Mutual TLS (mTLS)

mTLS اجازه می‌دهد backend اپلیکیشن را احراز هویت کند. اپلیکیشن از یک کلید خصوصی برای احراز هویت به backend استفاده می‌کند، که کلید عمومی مرتبط یا CA آن را تایید می‌کند. این امکان شناسایی ارتباط‌های غیرمجاز را فراهم می‌کند و bypassهای سمت کلاینت را کاهش می‌دهد.

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

۳. Application-Layer Encryption

رمزگذاری لایه اپلیکیشن یک لایه امنیتی اضافی فراتر از TLS ارائه می‌دهد. با رمزگذاری payload قبل از TLS، پراکسی MitM نمی‌تواند به‌صورت خودکار آن را رمزگشایی کند. مهاجم باید اپلیکیشن شما را مهندسی معکوس کرده و کلید رمزگذاری را بازیابی کند. می‌توان با obfuscation، RASP و ذخیره امن این مقاومت را افزایش داد.

۴. Application Attestation

Application Attestation تأیید می‌کند که درخواست از یک اپلیکیشن بدون دستکاری روی دستگاه معتبر آمده است، یعنی دستگاه روت یا جیلبریک نیست و روی امولاتور اجرا نمی‌شود. اپلیکیشن metadata زمان اجرا را جمع‌آوری کرده و به یک طرف سوم معتبر می‌فرستد و توکنی دریافت می‌کند که backend آن را اعتبارسنجی و رمزگشایی می‌کند. برخی راهکارها حتی توکن را به یک درخواست خاص bind می‌کنند و دستکاری زمان واقعی را تشخیص می‌دهند.

جدول خلاصه: محافظت در برابر دستکاری درخواست

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

چگونه از Bot Farms جلوگیری کنیم

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

راهکارها در برابر Bot farms:

تنها Application Attestation در این زمینه مؤثر است و اطمینان می‌دهد درخواست‌ها از اپلیکیشن‌های تغییرنیافته می‌آیند.

محافظت سمت سرور

در حالی که دفاع‌های سمت کلاینت مهاجمان را کند می‌کنند، حفاظت سمت سرور آن‌ها را متوقف می‌کند.

• استفاده از Rate limiting برای محدود کردن API بر اساس کاربر، IP یا دستگاه، به ویژه برای عملیات حساس مانند ورود، خرید و redemption.

• اجرای کنترل دسترسی دقیق با استفاده از قواعد مبتنی بر نقش یا محدودیت جغرافیایی.

• مانیتورینگ ترافیک API برای شناسایی الگوهای مشکوک، payloadهای تکراری و تحلیل رفتاری برای تشخیص اتوماسیون و reconnaissance.

محافظت مؤثر از بات‌ها، از حساب‌های جعلی، سوءاستفاده از تخفیف‌ها، تحلیل‌های مخدوش و بار اضافی backend جلوگیری می‌کند و بازده سرمایه‌گذاری امنیتی بالایی دارد.

نتیجه‌گیری: مانند یک هکر فکر کنید

هنگام طراحی لایه ارتباطی اپلیکیشن موبایل، آن را با بهترین شیوه‌ها و ابزارهای OWASP MASVS و اسکنرهای خودکار مانند AppSweep آزمایش کنید.

پس از پیاده‌سازی پایه‌ها، از obfuscation و RASP برای محافظت در برابر دستکاری و حملات واقعی استفاده کنید. تمامی تکنیک‌های کلاسیک سمت سرور وب نیز باید با همان دقت در backend موبایل اجرا شوند.

امنیت واقعی یعنی مانند مهاجم فکر کردن و یک قدم جلوتر بودن از او.