تست امنیت اپلیکیشن موبایل؛ راهنمای OWASP MASVS

یک اپلیکیشن بانکی ممکن است هیچ رمز عبوری را در فایل‌ها ذخیره نکند و تمام ترافیکش هم HTTPS باشد، اما هنوز با یک Deep Link دستکاری‌شده انتقال وجه را برای حساب اشتباه باز کند، پس از خروج توکن را معتبر نگه دارد یا مبلغ را فقط در کلاینت کنترل کند. این مثال نشان می‌دهد تست امنیت اپلیکیشن موبایل نه اسکن یک فایل APK یا IPA، بلکه ارزیابی یک سیستم شامل کلاینت، سیستم‌عامل، API، سرویس‌های ثالث، فرایند Build و داده‌های کاربر است.

در این راهنمای عملی یاد می‌گیریم چگونه برای Android و iOS دامنه و مجوز تست را تعریف کنیم، ریسک را به کنترل‌های OWASP MASVS و تست‌های MASTG نگاشت دهیم، تحلیل استاتیک و پویا را ترکیب کنیم و یافته‌ای تولید کنیم که قابل بازتولید، اولویت‌بندی و Retest باشد. مثال محوری، اپلیکیشن پرداخت ایرانی است؛ جایی که شماره موبایل، کد ملی، ریال و تومان، OTP، PSP و Callback هرکدام سطح حملهٔ جداگانه‌ای می‌سازند.

تست امنیت اپلیکیشن موبایل دقیقاً چه چیزی را می‌سنجد؟

هدف، اثبات «امن‌بودن مطلق» برنامه نیست؛ چنین اثباتی با یک دوره تست ممکن نیست. هدف این است که برای دارایی‌ها و سناریوهای تهدید مشخص، شواهدی دربارهٔ اثربخشی کنترل‌ها به دست آوریم، ضعف‌ها را با اثر واقعی آن‌ها توضیح دهیم و ریسک باقی‌مانده را به صاحب اختیار گزارش کنیم. راهنمای رسمی فرایند تست امنیت موبایل OWASP نیز ارزیابی را بخشی از بررسی معماری Client–Server و APIهای پشت اپ می‌داند، نه کاری محدود به خود باینری.

مرز سیستم موبایل از فایل نصب بزرگ‌تر است

حداقل شش سطح را در Scope ببینید:

• باینری و کد کلاینت: APK/AAB یا IPA، کتابخانه‌های Native، منابع، Symbolها و تنظیمات Build؛
• تعامل با پلتفرم: Permission، Intent، Deep Link، WebView، Keychain/Keystore، Clipboard، Backup و Screenshot؛
• شبکه و API: TLS، احراز هویت، مجوزدهی سطح شیء و عملیات، Rate Limit، Idempotency و مدیریت Session؛
• زنجیرهٔ تأمین: SDK تبلیغات/تحلیل، Dependency، Plugin ساخت، Signing Key و مسیر انتشار؛
• حریم خصوصی: جمع‌آوری، رضایت، حداقل‌سازی، نگهداری، اشتراک، حذف و داده‌های Telemetry؛
• عملیات: تنظیم محیط، Secret، Feature Flag، لاگ، مانیتورینگ، ابطال توکن و پاسخ به رخداد.

برای مبانی وسیع‌تر، ابتدا راهنمای تست امنیت نرم‌افزار و برای کیفیت کلی موبایل، مقالهٔ استراتژی تست اپلیکیشن موبایل را ببینید. این صفحه مالک Intent تخصصی امنیت Android/iOS است.

تفاوت تست امنیت با تست عملکردی عادی

تست عملکردی می‌پرسد «کاربر مجاز می‌تواند کارت خود را حذف کند؟»؛ تست امنیت می‌پرسد «آیا کاربر A با تغییر شناسه می‌تواند کارت کاربر B را حذف کند؟ آیا عملیات پس از Logout یا با توکن دستگاه گم‌شده هم انجام می‌شود؟ آیا پاسخ خطا وجود حساب را افشا می‌کند؟» بنابراین ورودی فقط مسیر مطلوب نیست؛ هویت، اعتماد، حالت، ترتیب رویداد، مرز بین کلاینت و سرور و سوءاستفاده نیز بخشی از Test Basis است.

پیش‌شرط غیرقابل مذاکره: مجوز کتبی و Rules of Engagement

تحلیل پویا، رهگیری ترافیک، Instrumentation، Fuzzing یا تلاش برای دورزدن کنترل‌ها می‌تواند مخرب یا از نظر حقوقی حساس باشد. قبل از اجرا یک RoE مکتوب داشته باشید: مالک سامانه، نسخه و محیط مجاز، حساب‌ها و IPهای تست، ساعت اجرا، سقف نرخ، داده‌های ممنوع، تکنیک‌های مجاز/غیرمجاز، Stop Condition، مخاطب اضطراری، شیوهٔ نگهداری شواهد و زمان حذف آن‌ها. نبود مجوز را با «این محیط تستی است» جبران نکنید.

نقشهٔ OWASP Mobile: Top ۱۰، MASVS، MASTG و MASWE

چهار خروجی OWASP نقش یکسان ندارند. اشتباه رایج آن است که Mobile Top ۱۰ را چک‌لیست کامل ممیزی بدانیم یا هر هشدار ابزار را «عدم انطباق با OWASP» بنامیم.

هر منبع چه کاری انجام می‌دهد؟

• Mobile Top 10: زبان آگاهی و اولویت‌بندی برای ده خانوادهٔ ریسک رایج است؛ نسخهٔ نهایی ۲۰۲۴ OWASP Mobile Top ۱۰ نقطهٔ شروع است، نه پوشش کامل یا برنامهٔ تست.
• MASVS: استاندارد کنترل‌های قابل بررسی است؛ یعنی می‌گوید چه خاصیت امنیتی باید برقرار باشد. OWASP MASVS هشت گروه Storage، Crypto، Auth، Network، Platform، Code، Resilience و Privacy دارد.
• MASTG: دانش، روش‌ها و رویه‌های ارزیابی را فراهم می‌کند. مجموعهٔ MASTG Atomic Tests هر تست را با گام، مشاهده و معیار ارزیابی مشخص می‌کند.
• MASWE: کاتالوگ ضعف‌های موبایل است و بین کنترل، تست و ضعف قابل مشاهده Traceability ایجاد می‌کند.

هشدار دربارهٔ سطح‌های قدیمی L1، L2 و R

از MASVS نسخهٔ ۲.۰، سطح‌های Verification قدیمی داخل خود استاندارد وجود ندارند و جهت‌گیری جدید به سمت Testing Profileهای مبتنی بر ریسک رفته است. پس صرفاً نوشتن «اپ ما MASVS-L2 است» بدون نسخهٔ استاندارد، Profile، کنترل‌های انتخاب‌شده، استثناها و شواهد، ادعای قابل ممیزی نیست. برای هر Release یک Baseline نسخه‌دار بسازید و دلیل Applicable یا Not Applicable بودن هر کنترل را ثبت کنید.

نگاشت Mobile Top ۱۰ ۲۰۲۴ به تست، نه جایگزینی تست

یک ردیف ممکن است به چند کنترل MASVS و چند تست MASTG متصل شود. Traceability باید از دارایی و تهدید به کنترل و تست برود؛ شمارهٔ Top ۱۰ به‌تنهایی Test Case نیست.

پیش از ابزار: Scope و پروفایل ریسک را بسازید

دارایی و جریان داده را روی کاغذ بیاورید

دارایی‌ها فقط Password نیستند. Refresh Token، کلید خصوصی، شماره کارت Mask‌شده، کد ملی، دفترچه مخاطبان، موقعیت، پیام OTP، رسید، موجودی، شناسه Device، Push Token و حتی الگوی رفتار کاربر می‌توانند حساس باشند. برای هرکدام Source، مقصد، پردازش، Storage، Third Party، Retention، حذف و Trust Boundary را ثبت کنید. سپس تهدیدها را با قابلیت مهاجم تعریف کنید: اپ مخرب روی دستگاه، شبکهٔ خصمانه، دستگاه گم‌شده و Unlock‌شده، کاربر عادی کنجکاو، حساب تصاحب‌شده، SDK آلوده یا مهاجم Backend.

هویت دقیق چیزی که تست می‌شود

گزارش «نسخهٔ آخر تست شد» بازتولیدپذیر نیست. Test Manifest حداقل شامل این موارد باشد:

• Version Name/Code یا Bundle Version، Git SHA، Build type و SHA-۲۵۶ Artifact؛
• Package/Bundle ID، گواهی Signing و منبع دریافت فایل؛
• محیط و Base URLهای Backend، Feature Flagها و نسخهٔ API؛
• مدل دستگاه، معماری CPU، نسخه و Patch Level سیستم‌عامل، Root/Jailbreak state؛
• نقش و Tenant حساب تست، وضعیت داده و زمان اجرای سناریو؛
• نسخهٔ MASVS/MASTG، کنترل‌های منتخب، استثنا و دلیل آن.

عمق تست را با اثر و احتمال انتخاب کنید

اپ کاتالوگ عمومی با اپ کیف پول یک Profile یکسان نمی‌خواهد. حساسیت داده، ارزش تراکنش، مجوزهای سیستم‌عامل، Exposure عمومی، کاربرد آفلاین، تهدید Root/Jailbreak، الزامات قراردادی و هزینهٔ سوءاستفاده را امتیازدهی کنید. نتیجه باید به افزایش یا کاهش عمق مشخصی منجر شود: مثلاً Instrumentation دستی برای منطق امضای تراکنش، آزمون Session روی چند دستگاه یا بررسی دقیق SDKهایی که PII دریافت می‌کنند. این تصمیم را در یک Risk Register نسخه‌دار با دلیل انتخاب یا حذف هر کنترل ثبت کنید.

روش گام‌به‌گام تست امنیت Android و iOS

۱. آماده‌سازی و Rules of Engagement

Scope، نقش‌ها، حساب‌ها، دادهٔ مصنوعی، تکنیک‌ها و محدودیت نرخ را تصویب کنید. برای White-box دو Build بخواهید: Release واقعی برای سنجش کنترل‌ها و یک Debug/Test Build کنترل‌شده برای مشاهده‌پذیری. تفاوت این دو را ثبت کنید؛ نتیجهٔ Debug جای نتیجهٔ Release را نمی‌گیرد.

۲. Discovery و نقشهٔ سطح حمله

صفحه‌ها، APIها، Scheme/Universal Link/App Link، Exported Component، Push Notification، WebView، File Import، Share، Bluetooth/NFC، Callback، Background Task و SDKها را فهرست کنید. هر Entry Point را به نقش، داده، پیش‌شرط و Side Effect وصل کنید. خروجی این مرحله Attack Surface Map است، نه یک لیست ابزار.

۳. تحلیل استاتیک Source و باینری

با دسترسی Source، Data flow از ورودی تا Sink حساس، Crypto use، Secret، Logging، Permission، Dependency و Build config را بررسی کنید. روی Artifact نیز Manifest/Entitlement، Certificate، URL، Resource، Symbol، Library و تفاوت Release/Debug را ببینید. Obfuscation نبودن، به‌تنهایی Vulnerability نیست؛ باید سناریوی اثر داشته باشد. همچنین Scanner coverage را معادل Test coverage نگیرید؛ راهنمای تحلیل استاتیک کد برای QA شیوهٔ Triage را شرح می‌دهد.

۴. تحلیل پویا روی برنامهٔ در حال اجرا

دادهٔ File/Database/Preference/Keychain/Keystore، Memory، Log، Clipboard، Screenshot و Backup را در حالت‌های قبل ورود، حین Session، Background، Lock، Logout و Uninstall/Restore مشاهده کنید. ترافیک را فقط در محدودهٔ مجاز رهگیری و تغییر دهید. ابزار خودکار ممکن است False Positive و False Negative داشته باشد؛ صفحهٔ رسمی ابزارهای MASTG نیز خروجی ابزار را نتیجهٔ قطعی امنیت نمی‌داند.

۵. آزمون هویت، حالت و منطق کسب‌وکار

دو یا چند حساب با نقش‌های متفاوت بسازید و Object/Action/Owner/Tenant را در درخواست‌ها تغییر دهید. Login، Refresh، Logout، Reset Password، تعویض شماره، ثبت دستگاه، Biometrics و Recovery را به‌صورت State Machine ببینید. Duplicate، Retry، درخواست دیررس، ترتیب معکوس و Race در عملیات مالی را تست کنید. برای طراحی عمیق Endpointها از راهنمای تست API استفاده کنید.

۶. آزمون تعامل با سیستم‌عامل و اپ‌های دیگر

ورودی‌های IPC، Intent/URL Scheme، File Provider، Share Extension، Notification Action، Pasteboard و WebView را از یک منبع غیرقابل اعتماد فرض کنید. مجوز باید در لحظهٔ اقدام حساس و در Backend یا مرز مورد اعتماد اعمال شود؛ مخفی‌کردن دکمه یا کنترل‌کردن Route در کلاینت مجوزدهی نیست.

۷. Privacy و زنجیرهٔ تأمین

رفتار واقعی برنامه و SDKها را با Privacy Notice و انتخاب کاربر تطبیق دهید. Dependency lockfile، منبع Artifact، امضا، SBOM، Vulnerability قابل بهره‌برداری، Secretهای Build و دسترسی CI را بررسی کنید. نسخهٔ آسیب‌پذیر بدون Reachability یا مسیر اثر هنوز نیازمند Triage است؛ در مقابل SDK سالمی که دادهٔ بیش از نیاز می‌فرستد مشکل Privacy دارد.

۸. تأیید دستی، Exploitability و اثر

یافتهٔ Scanner را با نسخهٔ دقیق، پیش‌شرط، مسیر تکرار و Observation تأیید کنید. لازم نیست برای اثبات اثر دادهٔ واقعی کاربر را استخراج یا سرویس را مختل کنید؛ کم‌خطرترین Proof کافی را انتخاب کنید. Severity تکنیکی را با حساسیت داده، نقش، تعداد کاربران، قابلیت تکرار، کنترل‌های جبرانی و اثر مالی/حریم خصوصی تکمیل کنید.

۹. اصلاح، Regression و Retest

پس از Fix، همان Artifact و Test Case را با Build جدید اجرا کنید، سپس Regression پیرامون کنترل را بسنجید. «هشدار ابزار ناپدید شد» فقط یک Observation است؛ ممکن است Rule، Scope یا قابلیت تحلیل تغییر کرده باشد. Retest باید علت بسته‌شدن، نسخهٔ Artifact و شواهد جدید را ثبت کند.

تست‌های اختصاصی Android و iOS

چک‌های حیاتی Android

• Manifest و Component: Activity، Service، Receiver و Provider غیرعمومی را android:exported="false" نگه دارید و برای موارد عمومی Permission و ورودی را بررسی کنید. چک‌لیست امنیت Android دربارهٔ Export و WebView راهنمای رسمی دارد.
• Intent و PendingIntent: Explicit بودن مقصد، Mutability Flag، Extraهای خصمانه و Reuse را بیازمایید؛ تصمیم حساس را به Extra اعتماد ندهید.
• App Link و Deep Link: Host/Path، تأیید دامنه، Routeهای قبل ورود، Redirect و پارامترهای مبلغ/مقصد را بررسی کنید.
• WebView: JavaScript Interface، File access، Mixed content، URL allowlist، Download و بازشدن Schemeهای خارجی را کنترل کنید.
• Storage: Shared Preference، SQLite/Room، Cache، External Storage، Logcat، Backup و Recent-app snapshot را در همهٔ Stateها ببینید.
• Network Security Config: Cleartext، Trust anchor، Debug override و Exception دامنه‌ای را روی Release تأیید کنید. مستند رسمی Network Security Configuration مرز این تنظیمات را توضیح می‌دهد.
• Keystore: Key material نباید Export شود؛ User authentication requirement، Invalidated key و Error path را آزمایش کنید.

چک‌های حیاتی iOS

• Entitlement و Info.plist: Capability، URL Scheme، Associated Domains، Background Mode، Query Scheme و Purpose String اضافی را حذف کنید.
• Universal Link و Custom Scheme: Claim شدن Scheme توسط اپ دیگر، مسیر قبل احراز هویت، Redirect و ورودی تاییدنشده را آزمایش کنید.
• Keychain: Access Group، Synchronizable، Accessibility class، حذف در Logout و دسترسی در Device lock state را مطابق مدل تهدید بررسی کنید. Apple Keychain Services مخزن رسمی Secretهای کوچک است؛ استفاده از آن بدون تنظیم دسترسی درست، به‌تنهایی تضمین امنیت نیست.
• Data Protection: کلاس حفاظت فایل و امکان دسترسی هنگام Lock/First Unlock را برای دادهٔ حساس بسنجید.
• App Transport Security: Exceptionهای دامنه‌ای و سراسری را روی Release ممیزی کنید. راهنمای Apple ATS نشان می‌دهد ATS به‌صورت پیش‌فرض اتصال‌هایی را که حداقل‌های TLS را ندارند مسدود می‌کند.
• Pasteboard، Log و Snapshot: OTP، شماره کارت، موجودی و رسید نباید ناخواسته در Clipboard، Console یا App Switcher بماند.
• Jailbreak/Instrumentation: اگر Resilience الزام ریسک است، تشخیص و واکنش را بسنجید؛ اما آن را جایگزین کنترل سرور نکنید.

یک Test Case مشترک، دو پیاده‌سازی متفاوت

الزام «توکن حساس خارج از Sandbox افشا نشود» مشترک است؛ Evidence در Android ممکن است Keystore، Auto Backup و Logcat باشد و در iOS به Keychain accessibility، Data Protection و Console مربوط شود. استاندارد را در سطح خاصیت مشترک نگه دارید و روی هر پلتفرم Test Procedure مستقل بنویسید.

کنترل‌های حیاتی و روش آزمون آن‌ها

Storage: داده را در همهٔ حالت‌ها ردیابی کنید

فقط پوشهٔ Documents یا Shared Preferences را یک‌بار نبینید. سناریو بسازید: ورود، دریافت OTP، نمایش رسید، Background، Lock، Force Stop، Logout، تعویض حساب، Backup/Restore و Uninstall/Reinstall. در هر مرحله File، Database، Cache، Preference، Keychain/Keystore reference، Log، Crash report، Clipboard، Notification و Screenshot را بررسی کنید. رمزگذاری داده‌ای که Key کنار آن Hardcode شده یا Plaintext در Log می‌رود کنترل مؤثری نیست.

Crypto: الگوریتم نام‌دار کافی نیست

مصرف Crypto را به هدف، کلید و Lifecycle وصل کنید: کلید کجا ساخته و نگهداری می‌شود؟ Nonce/IV تکرار می‌شود؟ Random امن است؟ Integrity هم لازم است؟ Rotation، Migration و Failure چه می‌کنند؟ به‌جای ساخت الگوریتم اختصاصی از APIهای معتبر پلتفرم استفاده کنید. Obfuscation، Base64 یا Hash بدون مدل کاربرد، Encryption نیست.

Authentication، Authorization و Session

• پاسخ Login/Recovery نباید وجود حساب را بی‌دلیل افشا کند؛ Rate و Abuse control را نیز بسنجید.
• توکن را از نظر Audience، Scope، Expiry، Rotation، Replay، Logout، Password reset و Device revoke تست کنید.
• Biometric معمولاً Unlock محلی یک Secret یا Action است؛ Backend نباید صرف ادعای کلاینت را احراز هویت تلقی کند.
• برای هر API، Role × Action × Object Owner × Tenant را تست کنید؛ UI مخفی، Authorization نیست.
• تغییر SIM/شماره، نصب مجدد، دستگاه دوم، Clock skew و Recovery را به Stateهای هویت اضافه کنید.

Network: فراتر از دیدن قفل HTTPS

Cleartext، نسخه و Cipher TLS، Certificate chain، Hostname، Redirect به HTTP، Proxy setting، User CA، Debug trust، خطای شبکه و Fail-open را بررسی کنید. Certificate Pinning برای هر اپ الزام جهانی نیست و هزینهٔ Rotation/Availability دارد؛ اگر بر اساس Threat Model انتخاب شده، Pin set، Backup pin، Expiry، Fail behavior و فرایند اضطراری آن را تست کنید. در هر حال Authorization و اعتبار داده باید در سرور برقرار بماند.

ورودی، WebView و مرز پلتفرم

هر داده از Deep Link، QR، Clipboard، File، Notification، Intent، URL Scheme، Web content و API را Untrusted بدانید. Length، Type، Unicode، مسیر، Scheme، Host، Redirect و Canonicalization را بررسی کنید. برای فارسی، تفاوت «ی/ی»، «ک/ک»، نیم‌فاصله، ارقام فارسی/عربی/لاتین و جهت RTL می‌تواند Validation، Allowlist یا نمایش مبلغ را تغییر دهد. Sanitization را جای Validation دامنه‌ای ننشانید.

Privacy: رفتار واقعی را با ادعا مقایسه کنید

برای هر داده بپرسید: ضرورت چیست، رضایت یا مبنای مجاز کدام است، SDK دریافت‌کننده کیست، Retention چقدر است، آیا کاربر می‌تواند دسترسی/حذف را کنترل کند و آیا داده در Analytics/Crash log نیز تکرار می‌شود؟ Permission دیالوگ سیستم‌عامل، توضیح Purpose، رفتار هنگام Deny و Revoke و حداقل‌سازی را تست کنید. دادهٔ تست شامل شماره موبایل و کد ملی واقعی نسازید؛ راهکارهای امن در مدیریت داده تست آمده است.

Resilience و تمامیت اپ

Anti-debug، Root/Jailbreak detection، Obfuscation، Integrity signal و Anti-tamper می‌توانند هزینهٔ حمله را بالا ببرند، اما Secret سمت کلاینت را غیرقابل استخراج یا تصمیم کلاینت را قابل اعتماد نمی‌کنند. واکنش نیز باید متناسب باشد: سیگنال کم‌اعتماد را می‌توان به Step-up verification یا محدودیت عملیات حساس وصل کرد؛ قفل‌کردن قطعی کاربر بر پایهٔ یک سیگنال شکننده ممکن است Availability و دسترس‌پذیری را آسیب بزند.

زنجیرهٔ تأمین و Build انتشار

Dependency و Pluginها را Pin و از منبع کنترل‌شده دریافت کنید، SBOM و مجوزها را نگه دارید، Secret را از Repository/Log/Artifact دور کنید و Build Release را با Policy خودکار بررسی کنید. SDK شخص ثالث را هم از نظر Vulnerability و هم رفتار داده/شبکه بسنجید. امضای Artifact، دسترسی Signing key، Separation of duties و Provenance Build بخشی از سطح حمله‌اند؛ Store review جای Security review شما نیست.

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

نقشهٔ ابزار به نوع شواهد

ابزار «بهترین» مطلق وجود ندارد. پلتفرم، نوع Artifact، سطح دسترسی، Skill تیم، امکان Self-host، محرمانگی Artifact، به‌روزرسانی Rule و خروجی قابل ادغام را با یک PoC بسنجید. مقایسهٔ خانواده‌ها در مقالهٔ ابزارهای تست امنیت تکمیل شده است.

ماتریس کوچک ولی معنادار دستگاه

برای هر ترکیب ریسک دلیل داشته باشید: جدیدترین OS روی دستگاه واقعی، قدیمی‌ترین نسخهٔ پشتیبانی‌شده، حداقل یک مدل پرتکرار، یک Emulator/Simulator برای تکرار سریع و در صورت مجازبودن یک دستگاه Root/Jailbreak کنترل‌شده. Architecture، Patch level، Locale فارسی، Biometric، Lock state، Network و App version را ثبت کنید. Emulator برای مشاهده‌پذیری عالی است، اما Secure hardware، Store distribution، Vendor ROM و برخی کنترل‌های Integrity را نمایندگی نمی‌کند. طراحی Device Matrix در راهنمای تست سازگاری آمده است.

ایمنی آزمایشگاه

دستگاه و حساب اختصاصی، شبکهٔ جدا، دادهٔ مصنوعی، Snapshot قابل بازیابی و Secretهای کوتاه‌عمر داشته باشید. Artifact مشتری را در سرویس آنلاین ناشناس Upload نکنید. شواهد ممکن است Token، PII یا Key داشته باشد؛ Mask، Encrypt، Access-control، Retention و Secure deletion را از ابتدا تعیین کنید.

مثال: تست امنیت یک اپلیکیشن پرداخت ایرانی

فرض کنید کاربر با شماره موبایل و OTP وارد می‌شود، کارت را ثبت می‌کند و پرداخت ریالی را از طریق PSP انجام می‌دهد. اپ Deep Link بازگشت از درگاه و Push رسید دارد. هدف Release: جلوگیری از پرداخت برای کاربر/سفارش دیگر، افشای Token و ثبت مبلغ اشتباه.

مدل دارایی، اعتماد و مهاجم

• دارایی: Access/Refresh token، شماره کارت Mask‌شده، کد ملی، Order ID، مبلغ ریال، PSP reference و رسید؛
• مرز اعتماد: اپ↔API، API↔PSP، Deep Link↔اپ، Push provider↔دستگاه و SDK Analytics؛
• مهاجم: کاربر عادی با حساب خودش، اپ مخرب روی دستگاه، Proxy شبکه و دارندهٔ دستگاه Unlock‌شده؛
• اصل: مبلغ، مالک سفارش و وضعیت پرداخت فقط با دادهٔ معتبر سرور و Callback تأییدشده تغییر کند.

سناریوهای باارزش

1. پارامتر orderId در Deep Link بازگشت را به سفارش کاربر دیگر تغییر دهید؛ اپ نباید دادهٔ آن سفارش را نمایش دهد و Backend نباید مالکیت را نادیده بگیرد.
2. مبلغ نمایشی را از تومان به ریال یا با رقم فارسی/لاتین تغییر دهید؛ سرور باید مبلغ مرجع را از Order خود بخواند، نه از کلاینت.
3. Callback یکسان PSP را تکرار، دیر ارسال و با ترتیب معکوس شبیه‌سازی کنید؛ Side Effect مالی باید Idempotent و قابل Reconcile باشد.
4. پس از Logout، Access و Refresh token قبلی را روی دستگاه دوم امتحان کنید؛ رفتار مورد انتظار ابطال باید با Policy محصول منطبق باشد.
5. اپ را در Background و App Switcher ببینید؛ موجودی، OTP و شماره کارت نباید در Snapshot یا Notification ناامن ظاهر شود.
6. Release Artifact را برای Debug flag، Test PSP URL، Cleartext exception، Log حساس و کلید Hardcoded بررسی کنید.
7. دسترسی مخاطبان را Deny و سپس Revoke کنید؛ پرداخت عادی نباید بی‌دلیل متوقف شود و دادهٔ قبلی باید مطابق Policy حذف شود.
8. ترافیک SDK Analytics را مشاهده کنید؛ Token، کد ملی، PAN، OTP و متن آزاد کاربر نباید ارسال شود.

Oracle مستقل و نتیجهٔ مورد انتظار

فقط Toast «موفق» را Oracle نگیرید. وضعیت Order و Ledger خواندنی، رویداد Audit، PSP sandbox record و پاسخ API را با Correlation ID تطبیق دهید. موفقیت یعنی دقیقاً یک پرداخت برای سفارش و مالک صحیح، مبلغ Canonical بر حسب ریال، عدم افشای داده و ثبت Audit قابل پیگیری. اگر PSP sandbox در دسترس نیست، Virtual service باید Contract و خطاهای واقعیِ شناخته‌شده را نسخه‌دار بازنمایی کند و محدودیتش در گزارش بیاید.

جای تست امنیت موبایل در CI/CD

لایه‌های بازخورد، نه یک اسکن سنگین آخر کار

• هر Commit: Secret scan، Dependency policy، lint امنیتی و Unit test برای Validation/Crypto wrapper/Authorization client contract؛
• Pull Request: SAST تغییرمحور، Manifest/Entitlement diff، Permission/ATS/Network-config policy و API regression؛
• Build Artifact: امضا/Hash، SBOM، Debug flag، Endpoint و Binary scan روی همان فایل نامزد انتشار؛
• Nightly: Emulator/Simulator dynamic smoke، API abuse cases و Dependency full scan؛
• پیش از Release پرریسک: Review دستی، تست روی دستگاه واقعی، Business Logic، Privacy و Retest یافته‌های باز؛
• پس از انتشار: Crash/Abuse/Session anomaly و تغییرات Backend را بدون جمع‌آوری بیش از نیاز مانیتور کنید.

Gate باید قابل اجرا باشد: مثلاً «یافتهٔ تأییدشدهٔ Critical/High بدون پذیرش ریسک معتبر و تاریخ انقضا اجازهٔ Promotion ندارد». تعداد هشدار یا صفرشدن Scanner معیار کافی نیست. طراحی Laneها را با اصول تست مداوم در CI/CD هماهنگ کنید.

قرارداد اتوماسیون امنیت

هر Job باید Scope، Rule/Profile version، Artifact hash، Tool version، Timeout، Exit semantics و Artifact خروجی داشته باشد. شکست ابزار، نبود Emulator یا ناقص‌شدن Scan نباید به‌اشتباه Pass محسوب شود؛ آن را Inconclusive/Infrastructure Failure جدا کنید. Baseline فقط با مالک، دلیل و Expiry قابل تغییر باشد و یافتهٔ قدیمی به‌دلیل Rename شدن Rule ناپدید نشود.

گزارش یافته‌ای که قابل تصمیم و Retest باشد

فیلدهای ضروری هر Finding

• عنوان مبتنی بر رفتار و اثر، شناسه، تاریخ، گزارشگر و وضعیت؛
• Artifact hash، Build، OS/device، محیط، نقش و پیش‌شرط؛
• دارایی/مرز متأثر و نگاشت MASVS/MASWE/MASTG با نسخه؛
• گام‌های حداقلی بازتولید، Expected، Actual و نرخ تکرار؛
• شواهد Mask‌شده: Request/Response، Screenshot، Log یا File path؛
• اثر فنی و کسب‌وکاری، قابلیت بهره‌برداری، دامنهٔ کاربران و کنترل جبرانی؛
• Severity، Priority، پیشنهاد اصلاح و مالک؛
• Fix version، Retest evidence و Regression scope.

Severity با Priority یکی نیست

Severity شدت اثر فنی/کسب‌وکاری را بیان می‌کند؛ Priority زمان و ترتیب رسیدگی را با Exposure، Release، تعهد و Fix cost ترکیب می‌کند. CVSS می‌تواند یک ورودی باشد، اما Context موبایل—مانند نیاز به دستگاه Unlock‌شده، Root، حساب معتبر یا حضور فیزیکی—باید شفاف ثبت شود. پذیرش ریسک وظیفهٔ تستر نیست؛ صاحب اختیار باید دلیل، کنترل جبرانی و تاریخ انقضا را امضا کند.

چگونه False Positive را کنترل کنیم؟

ابتدا Rule و محل Observation را بازسازی کنید، سپس Reachability، State، دادهٔ ورودی، کنترل‌های اطراف و اثر را بررسی کنید. سه خروجی معتبر وجود دارد: True Positive، False Positive با دلیل فنی، یا Needs Further Validation. «ابزار گفته» و «توسعه‌دهنده گفت امن است» هیچ‌کدام Evidence کامل نیست. False Negative را هم با Golden vulnerable sample، Review دستی و مقایسهٔ Scope پایش کنید.

چک‌لیست کوتاه آمادگی انتشار

• Artifact، امضا، Hash، محیط و Device/OS matrix نسخه‌دار ثبت شده‌اند.
• RoE، Test Profile و کنترل‌های Applicable/Exception تأیید شده‌اند.
• هیچ Secret، PII یا دادهٔ مالی در Code، Log، Cache، Backup، Clipboard و Snapshot افشا نمی‌شود.
• Authorization در Backend برای Role/Action/Object/Tenant و حالت‌های Retry/Race تست شده است.
• Session، Logout، Revocation، Recovery، Device change و Biometric مسیر انتظار روشن دارند.
• Deep Link/App Link/Universal Link، IPC، WebView، Notification و File input تست شده‌اند.
• TLS و Exceptionهای ATS/Network Security Config روی Release بررسی شده‌اند.
• Permission، Privacy notice، SDK telemetry، Retention و رفتار Deny/Revoke با واقعیت منطبق‌اند.
• Dependency/SBOM/Build provenance و دسترسی Signing/CI بررسی شده‌اند.
• یافته‌های Critical/High بسته، Retest یا با اختیار و Expiry پذیرفته شده‌اند.
• Regression و شواهد امن به Build نامزد انتشار متصل‌اند.
• Residual Risk و تصمیم Go/No-Go توسط صاحب اختیار ثبت شده است.

برنامهٔ ۳۰روزه برای ساختن قابلیت تست امنیت موبایل

هفتهٔ اول: Scope و Baseline

یک اپ و یک Journey حساس انتخاب کنید. Data Flow، Attack Surface، Artifact Manifest و RoE را بسازید. نسخهٔ MASVS را Pin و ۱۰ تا ۲۰ کنترل پرریسک را انتخاب کنید. وضعیت فعلی را بدون ادعای پوشش کامل ثبت کنید.

هفتهٔ دوم: تست دستی عمیق

روی Release واقعی، Storage، Network، Session، Authorization و Platform interaction را با دو نقش و دو دستگاه بررسی کنید. هر Finding را با قالب یکسان بنویسید و Scanner output را Triage کنید.

هفتهٔ سوم: بازخورد سریع

Secret/Dependency scan، Manifest/Entitlement policy و چند API abuse regression را به CI اضافه کنید. Fail/Inconclusive را جدا، Rule version را ثبت و Baseline را Expiryدار کنید.

هفتهٔ چهارم: Retest و تصمیم

Fixها را Retest، Regression را اجرا و Gapها را مرور کنید. سه متریک سالم انتخاب کنید: درصد کنترل‌های پرریسک با Evidence معتبر، زمان Triage یافتهٔ جدید و نرخ بازگشت Finding پس از Fix. تعداد خام هشدار را KPI موفقیت نکنید.

خطاهای رایج در تست امنیت موبایل

• برابر دانستن OWASP Mobile Top ۱۰ با برنامهٔ کامل تست؛
• گزارش Compliance بدون نسخه، Scope، Profile و Evidence؛
• اسکن APK/IPA و نادیده‌گرفتن Backend، API و Business Logic؛
• تست Debug build و تعمیم نتیجه به Release؛
• اعتماد به HTTPS، Pinning، Obfuscation یا Root detection به‌عنوان دفاع کامل؛
• ذخیرهٔ Secret در کلاینت با فرض اینکه مهاجم آن را نمی‌بیند؛
• اسکن فعال Production بدون مجوز، سقف نرخ و Stop Condition؛
• آپلود Artifact یا Evidence حساس در ابزار ثالث بدون ارزیابی داده؛
• بستن Finding فقط چون هشدار Scanner دیگر دیده نمی‌شود؛
• شمردن هشدارها به‌جای پوشش ریسک و اثربخشی کنترل.

سؤالات متداول

جمع‌بندی

تست امنیت اپلیکیشن موبایل زمانی ارزش دارد که از دارایی و تهدید آغاز شود، به کنترل نسخه‌دار MASVS و روش MASTG برسد و با Evidence روی همان Release خاتمه پیدا کند. Android و iOS تفاوت‌های اجرایی دارند، اما اصول مشترک‌اند: کلاینت را نامطمئن فرض کنید، تصمیم حساس را در مرز مورد اعتماد بگیرید، داده را در تمام Lifecycle دنبال کنید، ابزار را منبع سیگنال بدانید و ریسک باقی‌مانده را شفاف به صاحب اختیار بسپارید.