English
العودة إلى الخدمات

تقييم أمن تطبيقات الهاتف المحمول


تحليل Static وDynamic لتطبيقاتك على Android وiOS والـ Backend APIs التي تعتمد عليها، بما يتوافق مع OWASP MASVS.

التحدي

يصل التطبيق إلى آلاف الأجهزة التي لا تتحكم بها. فالـ Tokens تُحفظ في الـ Local Storage، والـ Deep Links تفتح شاشات لا ينبغي لها فتحها، والـ Backend يثق بعمليات تحقق لم تجرِ قط إلا على جهاز العميل (Client). ومراجعة متجر التطبيقات ليست مراجعة أمنية، والـ API خلف التطبيق لم تُختبر غالباً تحت Session صالحة.

في سطور
Grey Boxنموذج الوصول للاختبار
Android + iOSالمنصتان معاً، الـ Client والـ Backend
Static + Dynamicمراجعة الـ Binary والاعتراض المباشر (Interception)
4 خطواتمن الانطلاق إلى التقرير المعتمد

ما يشمله التقييم


تقيّم AZRE Consulting تطبيقات Android وiOS المشمولة بالنطاق عبر تحليل Static وDynamic مشترك، يغطي الـ Mobile Client نفسه والـ Backend APIs التي يعتمد عليها. ويتوافق الاختبار مع OWASP MASVS ومع OWASP Mobile Top 10.

  • التطبيقات: تطبيقات Android وiOS الأصلية (Native) ومتعددة المنصات (Cross-platform)، بجميع اللغات واتجاهات العرض المدعومة
  • الإصدارات: إصدارات Internal Distribution للمنصتين، بحيث يمكن اعتراض حركة البيانات عبر Proxy خاضع للرقابة حيث ترفض إصدارات الـ Release شهادات الـ CA التي يثبّتها المستخدم
  • أدوار المستخدمين: المسارات غير المصادَقة (Unauthenticated) كإنشاء الحساب واسترداده (Recovery) والتحقق من الهوية (eKYC)، والمستخدمون المصادَقون ممن أكملوا الـ Onboarding وممن لم يكملوه
  • الـ Backend APIs: الـ Backend-for-Frontend الخاص بتطبيق الهاتف، بما فيه الـ Endpoints المؤمّنة بـ Bearer Token، وغير المصادَقة، وCeremony Endpoints، وFile Upload، إلى جانب مسار الـ Identity Provider (OIDC) الذي يصادق التطبيق من خلاله
  • نموذج الوصول: Grey Box، مع حسابات اختبار لكل دور وإصدارات الـ Build اللازمة للاعتراض (Interception)

محاور الاختبار الرئيسية


  • Static Analysis: مراجعة الـ Binary والـ Source Code بحثاً عن Hardcoded Secrets وAPI Keys وCryptographic Material وDebug Artifacts والمكتبات الخارجية غير الآمنة
  • Insecure Data Storage: الـ Credentials والـ Tokens والبيانات الحساسة المحفوظة في قواعد البيانات المحلية وShared Preferences وKeychain وKeystore والـ Caches والـ Logs والـ Backups
  • Platform Interaction: الـ Exported Components، ومعالجة Deep Links وIntents، والـ IPC، وكشف الـ Clipboard، والـ Screenshot وBackground Caching، وإساءة استخدام الـ File Provider
  • Transport Security: تهيئة TLS، وCertificate Validation وPinning، والصمود أمام الاعتراض عبر Proxy خاضع للرقابة
  • Runtime وClient-Side Trust: كشف Root وJailbreak، وفحوصات الـ Debugger والـ Emulator، وCode Obfuscation، والـ Authorization أو Feature Gating المفروض على الـ Client بدل الـ Server
  • Authentication وSession Handling: تخزين الـ Tokens ودورة حياتها، ومسارات Biometric Authentication، وDevice Binding، وSession Invalidation عند تسجيل الخروج أو تغيير الـ Credentials
  • Backend API Testing: اختبار Authenticated كامل لسطح الـ Mobile API، بما فيه الـ Authorization وObject-level Access Control وBusiness Logic Abuse تحت Sessions صالحة

المنهجية


تسير جميع الأنشطة وفق أطر معترف بها في أمن التطبيقات وإدارة المخاطر، ومنها OWASP MASVS وOWASP Mobile Top 10 وOWASP API Security Top 10 وNIST SP 800-53 وSP 800-115، فضلاً عن متطلبات الضوابط الأمنية المحددة في ISO/IEC 27001 وSOC 2. ويجمع الاختبار بين الاستكشاف اليدوي المعمّق (Manual Testing) والتحليل الآلي الموجّه (Automated Analysis)، ويُتحقق من كل نتيجة يدوياً لاستبعاد الـ False Positives.

كيف يسير المشروع


يسير المشروع وفق عملية من أربع خطوات صُممت لتندمج في مسارات العمل الهندسية القائمة دون احتكاك تشغيلي أو توقف.

  • المواءمة والتهيئة: قائد مشروع مخصص وفريق اختبار يناسب حزمتك التقنية؛ واجتماع انطلاق للاتفاق على النطاق ومنطق الأعمال والمناطق المحظورة؛ وتسليم آمن للـ Builds وحسابات الاختبار وصلاحيات الوصول
  • الاختبار الفعلي والتعاون المباشر: اختبار يدوي معمّق (Manual Testing) إلى جانب التحليل الآلي، على تواصل دائم مع قادتك التقنيين؛ ويُبلَّغ عن أي نتيجة حرجة أو عالية الخطورة فور اكتشافها ليبدأ الإصلاح بالتوازي
  • التحليل والإحاطة التقنية: تقرير أولي شامل مع أدلة Proof-of-Concept وتوصيات Hardening قابلة للتنفيذ، يليه استعراض للنتائج مع فريقي الهندسة والمنتج
  • التحقق والإغلاق: Re-testing موجّه بعد تنفيذ الإصلاحات للتأكد من معالجة الـ Vulnerabilities كاملة ومن عدم ظهور Regressions، ثم إصدار التقرير النهائي المعتمد وأرشفة بيانات المشروع
ما تحصل عليه
  • إبلاغ فوري بكل نتيجة حرجة أو عالية الخطورة أثناء الاختبار
  • تقرير أولي مع أدلة Proof-of-Concept لكل نتيجة، على جانبي الـ Client والـ Backend
  • نتائج مصنّفة حسب درجة الخطورة ومرتبطة بضوابط MASVS، مع توصيات Hardening قابلة للتنفيذ
  • استعراض للنتائج مع فريقي الهندسة والمنتج لديك
  • Re-test موجّه لكل نتيجة جرت معالجتها
  • التقرير النهائي المعتمد

المحصلة


يصمد التطبيق والـ API خلفه على جهاز يتحكم به المهاجم، وتُفرض الضوابط المهمة على الـ Server بدل أن يُوثق بها على الـ Client.

الأطر التي نختبر وفقها
OWASP MASVSMobile App Security Verification
OWASP Mobile Top 10Mobile Application Risks
OWASP API Top 10API Security Risks
NIST SP 800-115Security Testing & Assessment
الخطوة التالية

ابدأ بحديث، لا بعرض سعر.


أخبرنا بما يجري في الشركة. إن لم نكن الجهة المناسبة، سنقول ذلك ونرشدك إلى جهة أفضل. وإن كنا الجهة المناسبة، فستخرج من الحديث بقراءة للمشكلة أوضح مما دخلت به.

ابدأ الحديث