تست نفوذ موبایل معمولاً به‌صورت «بررسی امنیت اپلیکیشن اندروید یا iOS» فروخته میشود، اما این توصیف نیمی از ماجرا را جا می‌گذارد. یک اپلیکیشن موبایل تقریباً همیشه یک پوسته‌ی کاربری روی یک API تحت وب است؛ داده‌ی واقعی، احراز هویت و منطق کسب‌وکار همه سمت سرور زندگی می‌کنند. تجربه‌ی عملی این است که آسیبپذیریهای سمت کلاینت مهم‌اند، اما یافتههای پرخطر — افشای داده‌ی کاربران دیگر، دور زدن مجوزدهی، ارتقای نقش — تقریباً همیشه در همان API کشف میشوند. این راهنما هر دو لایه را با نسبت درستشان توضیح می‌دهد.
در یک نگاه
- تست موبایل سه لایه دارد: کلاینت (ذخیرهسازی، باینری، مؤلفه‌های پلتفرم)، ارتباط (TLS و پین‌کردن گواهی) و سرور/API.
- چارچوب مرجع این حوزه، پروژهی OWASP MAS با استاندارد MASVS و راهنمای آزمون MASTG است.
- برای APIها مرجع درست OWASP API Security Top 10 است؛ کنترل دسترسی در سطح شیء (BOLA) پرتکرارترین یافته‌ی جدی است.
- پین‌کردن گواهی، تشخیص روت و مبهمسازی کد، سخت‌ترکردن کار مهاجم است، نه کنترل امنیتی سمت سرور.
تست نفوذ موبایل از چه لایه‌هایی تشکیل شده است؟
یک ارزیابی کامل موبایل سه سطح جدا دارد و هر سطح ابزار و مهارت خودش را می‌خواهد:
- لایهی کلاینت: آنچه روی دستگاه کاربر می‌گذرد — داده‌ی ذخیره‌شده‌ی محلی، فایلهای پیکربندی، لاگ‌ها، حافظه‌ی پنهان، محتوای باینری اپلیکیشن، و مؤلفه‌هایی که اپلیکیشن در اختیار سایر اپلیکیشن‌های دستگاه می‌گذارد.
- لایهی ارتباط: این‌که ترافیک واقعاً روی TLS معتبر می‌رود، گواهی سرور به‌درستی اعتبارسنجی میشود، و آیا پین‌کردن گواهی پیاده‌سازی شده است یا نه.
- لایهی سرور: همان API که اپلیکیشن با آن حرف می‌زند — و از نظر ریسک، مهم‌ترین لایه.
پروژهی OWASP Mobile Application Security برای این حوزه دو سند تولید کرده است: MASVS به‌عنوان استاندارد الزامات قابل‌راستی‌آزمایی، و MASTG به‌عنوان راهنمای آزمون فنی. MASVS کنترل‌ها را در گروه‌هایی مانند ذخیرهسازی، رمزنگاری، احراز هویت، شبکه، تعامل با پلتفرم، کیفیت کد و مقاوم‌سازی سازمان می‌دهد. نقشِ آن در دنیای موبایل همان نقشی است که WSTG در دنیای وب دارد. جزئیات سرویس ما در صفحه‌ی تست نفوذ موبایل آمده است.
چه چیزی سمت کلاینت بررسی میشود؟
سمت کلاینت، پرسش محوری این است: «اگر کسی دستگاه را در اختیار داشت، یا اگر اپلیکیشن مخرب دیگری روی همان دستگاه نصب بود، چه چیزی به دست می‌آورد؟»
| موضوع | در اندروید | در iOS |
|---|---|---|
| ذخیرهسازی ناامن | SharedPreferences، پایگاه‌داده‌ی SQLite، فایلهای حافظه‌ی خارجی | فایلهای plist، پایگاه‌داده‌ها، استفاده‌ی نادرست از Keychain |
| نگهداری کلید و توکن | Android Keystore در برابر رشته‌ی هاردکد در کد | Keychain با سطح دسترسی درست |
| سطح تماس با سایر اپ‌ها | مؤلفه‌های Exported، Intent، Content Provider، Deep Link | URL Scheme و Universal Link |
| مؤلفه‌ی نمایش وب | WebView با جاوااسکریپت یا دسترسی فایل فعال | WKWebView و پیکربندی آن |
| پشتیبان‌گیری و لاگ | مجاز بودن Backup، نشت داده در Logcat | گنجاندن داده‌ی حساس در پشتیبان |
| مقاوم‌سازی | تشخیص روت، بررسی امضا، مبهمسازی | تشخیص جیلبریک، بررسی یکپارچگی |
در اندروید، فایل APK قابل باز‌کردن و بازگردانی به کد میانی است؛ بنابراین هر رمز، کلید API یا آدرس سرویس داخلی که داخل اپلیکیشن جاسازی شده باشد را باید افشاشده فرض کرد. این نکته درست همان استدلالی است که در بازبینی کد برای اسرار جاسازیشده در مخازن به کار می‌رود.
«پین‌کردن گواهی و تشخیص روت اضافه کردیم، پس اپلیکیشن امن است.» این کنترل‌ها هزینه‌ی تحلیل را برای مهاجم بالا می‌برند و ارزش دارند، اما همه‌شان سمت کلاینت اجرا میشوند — یعنی روی دستگاهی که در اختیار مهاجم است. هر بررسی‌ای که فقط روی دستگاه انجام شود، در نهایت قابل غیرفعال‌سازی است. کنترل امنیتی واقعی باید سمت سرور و در هر درخواست اعمال شود؛ کلاینت هیچ‌وقت مرز اعتماد نیست.
چرا API پشت اپلیکیشن نقطه‌ی واقعی ریسک است؟
وقتی ترافیک اپلیکیشن را روی یک پروکسی میانی مشاهده می‌کنید، چیزی که می‌بینید مجموعه‌ای از درخواست‌های HTTP است — دقیقاً همان چیزی که در یک تست نفوذ وب بررسی میشود. و دقیقاً همان دسته آسیب‌پذیری‌ها هم اینجا ظاهر میشوند، اما با احتمال بیشتر؛ چون تیم‌ها اغلب فرض می‌کنند «این API فقط توسط اپلیکیشن ما مصرف میشود».
الگوی پرتکراری که در عمل دیده میشود این شکل را دارد:
GET /api/v2/users/1042/invoices HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...اپلیکیشن همیشه شناسه‌ی کاربر جاری را می‌فرستد، پس در آزمون‌های داخلی هیچ‌وقت مشکلی دیده نمی‌شود. اما هیچ چیز مانع نمی‌شود که همان توکن معتبر با شناسه‌ی 1043 فرستاده شود. اگر سرور مالکیت رکورد را بررسی نکند، این یک IDOR تمام‌عیار است — زیرمجموعه‌ای از کنترل دسترسی شکسته که در OWASP Top 10:2025 دسته‌ی A01 و رتبه‌ی یک است.
مرجع درست برای دسته‌بندی ریسک APIها، OWASP API Security Top 10 است که دسته‌های اختصاصی‌تری دارد: مجوزدهی شکسته در سطح شیء (BOLA)، مجوزدهی شکسته در سطح ویژگی (BOPLA) که همان مسئله‌ی انتساب انبوه است، مجوزدهی شکسته در سطح تابع (BFLA)، مصرف نامحدود منابع، و مدیریت نادرست فهرست نسخه‌های API. روش آزمون این موارد در تست امنیت API شرح داده شده است.
مسائل توکن هم اینجا متمرکز میشوند: اعتبارسنجی نادرست JWT، عمر طولانی توکن بدون سازوکار ابطال، و پیاده‌سازی ناقص OAuth در جریان ورود اپلیکیشن.
روش انجام تست نفوذ اندروید و iOS
ترتیب کاری که در عمل جواب می‌دهد:
- تحلیل ایستا: باز کردن بسته‌ی اپلیکیشن، بررسی فایل مانیفست و مجوزها، فهرست مؤلفه‌های در معرض دید، جست‌وجوی اسرار و آدرس‌های سرویس در باینری و منابع.
- راه‌اندازی مشاهده‌ی ترافیک: نصب گواهی ریشه‌ی پروکسی روی دستگاه آزمایشی و هدایت ترافیک به Burp Suite یا Caido. برای اپلیکیشن‌هایی که تنظیم پروکسی سیستم را نادیده می‌گیرند یا گواهی را پین کرده‌اند، ابزارهای اسکریپت‌پذیر مانند mitmproxy انتخاب بهتری هستند.
- تحلیل پویا روی دستگاه آزمایشی: بررسی فایلهای ساخته‌شده در حین اجرا، محتوای پایگاه‌داده‌ی محلی، لاگ‌ها و رفتار اپلیکیشن در حالت پس‌زمینه.
- آزمون API: بخش سنگین کار. ساخت حداقل دو حساب با نقش‌های متفاوت، ثبت کامل مجموعه‌ی درخواست‌ها، و بازپخش هر درخواست با نشست دیگری — همان روشی که ماتریس مجوزدهی را می‌سازد.
- آزمون منطق کسب‌وکار: جریان‌های پرداخت، بازگشت وجه، امتیاز و تخفیف. هیچ اسکنری این‌ها را پیدا نمیکند.
توجه کنید که همه‌ی این کارها باید روی دستگاه و حساب‌های آزمایشی و در چارچوب یک قرارداد و مجوز کتبی انجام شود. تحلیل اپلیکیشن دیگران یا دستکاری ترافیک کاربران واقعی، خارج از چارچوب حرفه‌ای و قانونی است — تفکیک این مرز در تفاوت هک و امنیت توضیح داده شده است.
اولویت‌بندی: بودجه را کجا خرج کنیم؟
اگر بودجه‌ی محدودی دارید و باید انتخاب کنید، این ترتیب از نظر کاهش ریسک واقعی منطقی‌تر است:
| اولویت | حوزه | دلیل |
|---|---|---|
| ۱ | API و لایهی سرور | افشای داده‌ی همه‌ی کاربران از یک نقص مجوزدهی امکانپذیر است |
| ۲ | احراز هویت و مدیریت نشست | ورود، بازیابی رمز و توکن‌ها — مسیر مستقیم تصاحب حساب |
| ۳ | ذخیرهسازی محلی و نشت داده | اثر معمولاً محدود به دستگاه همان کاربر است |
| ۴ | مقاوم‌سازی باینری و ضدتحلیل | هزینه‌ی مهاجم را بالا می‌برد اما آسیب‌پذیری را حذف نمیکند |
یک نتیجه‌ی عملی از این جدول: اگر سازمان شما هم برنامه‌ی وب دارد و هم اپلیکیشن موبایل که به همان API متصل میشود، تست عمیق آن API بیشترین بازده را دارد، چون هم‌زمان هر دو کانال را پوشش می‌دهد. تعیین این‌که چه چیزی داخل دامنه قرار بگیرد، موضوع دامنه‌بندی تست نفوذ است و برای انتخاب مسیر می‌توانید از مشاوره استفاده کنید. سرویس اصلی ما همچنان تست نفوذ برنامه‌های وب و API است.
پرسش‌های متداول
تست نفوذ اپلیکیشن موبایل با تست نفوذ وب چه تفاوتی دارد؟
تفاوت در لایهی کلاینت است: در موبایل باید باینری، ذخیرهسازی محلی و تعامل با پلتفرم را هم بررسی کرد. اما لایهی سرور در هر دو یکسان است و در عمل بیشتر یافتههای پرخطر همانجا کشف میشوند. به همین دلیل یک تست موبایل بدون آزمون جدی API، ناقص است.
آیا برای تست اپلیکیشن اندروید به گوشی روتشده نیاز است؟
برای بخشی از آزمونها بله — دسترسی به فایلهای داخلی اپلیکیشن و تحلیل پویای عمیق روی دستگاه آزمایشی روتشده یا شبیهساز انجام میشود. اما آزمون API و بررسی ترافیک روی دستگاه معمولی هم امکانپذیر است، و همان بخش است که بیشترین یافته را تولید میکند.
کد اپلیکیشن را مبهمسازی کردهایم؛ آیا کافی است؟
خیر. مبهمسازی خواندن کد را کندتر میکند و در برابر تحلیل خودکار سطحی مفید است، اما جلوی تحلیل هدفمند را نمیگیرد و هیچ اثری بر آسیبپذیریهای سمت سرور ندارد. هر کلید یا اسرار جاسازیشده در اپلیکیشن را باید افشاشده فرض کرد، حتی با مبهمسازی.
استاندارد مرجع تست امنیت موبایل چیست؟
پروژهی OWASP Mobile Application Security با دو سند MASVS (استاندارد الزامات) و MASTG (راهنمای آزمون). برای بخش API، مرجع درست OWASP API Security Top 10 است. توجه کنید که هیچکدام گواهینامهی رسمی صادر نمیکنند؛ ادعای «گواهی OWASP» بیمعناست.
آیا انتشار اپلیکیشن در بازار یا گوگلپلی به معنای بررسی امنیتی آن است؟
خیر. بازبینی فروشگاهها بر بدرفتاری اپلیکیشن، مجوزهای مشکوک و انطباق با قواعد فروشگاه تمرکز دارد، نه بر آسیبپذیریهای منطقی سرویس شما. کنترل دسترسی شکسته در API شما هیچ نشانهای برای فرایند بازبینی فروشگاه تولید نمیکند.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیرهسازی ناامن، تخصص اوست.