Android Security Assessment (MSTG)

Android application security assessment following OWASP MSTG

حول هذه الخدمة

تقييم أمن تطبيقات Android لدينا مراجعة واسعة لتطبيق Android يسترشد بمعيار OWASP MASVS ورفيقه في الاختبار OWASP MASTG. نختبر التطبيق من زوايا عدّة: البيانات التي يحتفظ بها على الجهاز (SharedPreferences، وقاعدة بيانات SQLite، والملفّات، والذواكر المؤقتة)، وكيفية تشفيره للبيانات وتخزينه للمفاتيح، والمكوّنات التي يعرضها لتطبيقات أخرى (activities وservices وbroadcast receivers وcontent providers) والاتصال بين العمليات الذي يتدفّق عبر عناصر intent، وأمن حركة شبكته والتعامل مع الشهادات، ومدى صموده أمام الهندسة العكسية والعبث. فالجهاز يُفقد أو يُشارَك أو تُفتح صلاحيات جذره بسهولة، لذا على التطبيق أن يصمد حين لا تكون المنصّة من حوله موضع ثقة. نتابع كلّ نتيجة حتى إثبات عملي، ونصنّفها وفق CVSS إلى جانب أثرها الفعلي، ونوثّقها مع إصلاح ملموس.

ما الذي تتضمّنه الخدمة

تخزين البيانات المحلية: SharedPreferences، وقاعدة بيانات SQLite، والملفّات، والتخزين الخارجي، والسجلّات، والذواكر المؤقتة

التشفير وإدارة المفاتيح، بما في ذلك استخدام Android Keystore

المكوّنات المُصدَّرة — activities وservices وbroadcast receivers وcontent providers — وأذوناتها

الاتصال بين العمليات عبر عناصر intent، وروابط deep link، وعناصر pending intent

المصادقة وإدارة الجلسات وتخزين الرموز (tokens) على الجهاز

الاتصال الشبكي وتهيئة TLS والتحقّق من الشهادات وتثبيتها (pinning)

تهيئة أمن الشبكة، وإعدادات WebView، واستخدام واجهات برمجة التطبيقات الخاصة بالمنصّة

الصمود أمام الهندسة العكسية والعبث: التعمية (obfuscation)، وكشف صلاحيات الجذر (root) والمنقِّح (debugger)، وإعادة التغليف

الأسرار على جانب العميل والمنطق الحسّاس المكشوف داخل ملفّ APK

الخصوصية: أيّ بيانات تغادر الجهاز، وإلى من، وبأيّ موافقة

كيف يعمل

1
تحديد النطاق والوصول
نتّفق على الحدود ونحدّد عمق الاختبار: الصندوق الأسود من ملفّ APK وحده، أو الصندوق الرمادي مع حسابات اختبار ووثائق، أو الصندوق الأبيض مع الوصول إلى الكود المصدري لأعمق تغطية. نطلب بناءً قابلاً للاختبار، وحسابات اختبار لكلّ دور، وبياناً بأيّ واجهة خلفية ينبغي أن تبقى خارج النطاق. وعادةً ما يجري الاختبار على واجهة خلفية staging كي لا تُمسّ بيانات الإنتاج ومستخدموه أبداً.
2
التحليل الساكن والتخزين
نفكّ ملفّ APK ونراجع ملفّ manifest والمكوّنات المُصدَّرة والأذونات وتهيئة أمن الشبكة. نشغّل التطبيق ونفحص ما يكتبه إلى التخزين — التفضيلات وقاعدة البيانات والملفّات والسجلّات والذواكر المؤقتة — وما إذا كان أيّ شيء حسّاس يبقى غير مشفَّر أو على التخزين الخارجي أو في نسخة احتياطية.
3
الاختبار الديناميكي والمنصّة
نختبر التطبيق أثناء تشغيله: المصادقة وإدارة الجلسات، والتشفير وتخزين المفاتيح، والمكوّنات المُصدَّرة وعناصر intent التي يمكن لتطبيقات أخرى الوصول إليها. نعترض حركة الشبكة للتحقّق من TLS والتحقّق من الشهادات وتثبيتها (pinning)، ونفحص روابط deep link وعناصر WebView وواجهات برمجة التطبيقات الخاصة بالمنصّة التي يعتمد عليها التطبيق.
4
الهندسة العكسية والصمود
نجري هندسة عكسية للتطبيق لنرى ما يراه مهاجم مصمِّم: الأسرار والمنطق المتروكان في الكود، ومدى صمود التطبيق أمام العبث وإعادة التغليف والتشغيل على جهاز بصلاحيات الجذر (root) أو مُعترَض (hooked). ويتوقّف المستوى المناسب من الصمود على ما يحميه التطبيق، ونحدّد نطاقه وفقاً لذلك.
5
التحقّق وإعداد التقرير وإعادة الاختبار
يُتحقّق من كلّ نتيجة بإثبات مفهوم قابل لإعادة الإنتاج، وتُربط بفئة MASVS التي تنتمي إليها، وتُصنَّف وفق CVSS والأثر الفعلي على العمل، وتُوثَّق مع إصلاح مرتّب بحسب الأولوية. وبعد معالجتكم، نعيد الاختبار للتأكّد من ثبات الإصلاحات.
المُخرجات
  • ملخّص تنفيذي مع نظرة عامة على المخاطر لصنّاع القرار
  • تقرير فنّي مفصّل، كلّ نتيجة مع إثبات مفهوم قابل لإعادة الإنتاج
  • نتائج مربوطة بفئات OWASP MASVS
  • نتائج التخزين والتشفير وإدارة المفاتيح الخاصة بالجهاز
  • نتائج المكوّنات المُصدَّرة والاتصال بين العمليات (IPC) والاتصال الشبكي
  • تقييم الهندسة العكسية والصمود محدَّد النطاق وفق خطر التطبيق
  • درجة خطورة CVSS والأثر على العمل لكلّ نتيجة
  • خارطة طريق للمعالجة مرتّبة بحسب الأولوية وإعادة اختبار بعد المعالجة

لماذا حافظ سيكيور

تغطية قائمة على المعايير
يتّبع التقييم OWASP MASVS وMASTG، فتكون التغطية عبر التخزين والتشفير والمصادقة والشبكة والمنصّة والصمود صريحة وقابلة للتحقّق بدلاً من أن تكون ارتجالية.
عمق في منصّة Android
نفهم كيف يعزل Android التطبيقات، وكيف تعرِض المكوّنات وعناصر intent التطبيق لغيره، وكيف يحمي Android Keystore المفاتيح، فنكتشف مخاطر المنصّة التي يفوتها الفاحص العامّ.
مهارة في الهندسة العكسية
ننظر إلى التطبيق كما يفعل مهاجم مصمِّم — بفكّ الترجمة (decompiling) والاعتراض (hooking) وتشغيله على جهاز بصلاحيات الجذر (root) — لاختبار الأسرار والدفاعات التي لا تظهر إلا تحت ضغط حقيقي.
نتائج قابلة للتنفيذ ومرتّبة بحسب الأولوية
إرشادات واضحة مرتّبة بحسب الخطر، مع إثبات مفهوم قابل لإعادة الإنتاج وإصلاح ملموس لكلّ نتيجة.

الأسئلة الشائعة

ما تقييم أمن تطبيقات Android؟

هو مراجعة أمنية واسعة لتطبيق Android يسترشد بـ OWASP MASVS وMASTG. يغطّي تخزين البيانات المحلية، والتشفير وإدارة المفاتيح، والمكوّنات المُصدَّرة والاتصال بين العمليات (IPC)، والاتصال الشبكي، واستخدام واجهات برمجة التطبيقات الخاصة بالمنصّة، والصمود أمام الهندسة العكسية — مع إثبات كلّ نتيجة وتصنيفها.

بم يختلف هذا التقييم عن خدمة التحقّق من MASVS لديكم؟

تتحقّق خدمة MASVS من تطبيق وفق مستوى ضمان MASVS مختار وتُبلّغ عن التغطية مقابل ذلك المعيار. أمّا هذا التقييم فهو الاختبار العملي الواسع الكامن تحته: نُشغّل التطبيق عبر التخزين والمنصّة والشبكة والصمود لاكتشاف مشكلات فعلية قابلة للاستغلال. وكثير من الفرق تُجري هذا أولاً وتلجأ إلى التحقّق حين تحتاج إلى شهادة بمستوى معيّن.

ما الوصول والمواد التي تحتاجونها؟

كحدٍّ أدنى، بناء للتطبيق يمكننا تثبيته وحسابات اختبار لكلّ دور مستخدم. ولتغطية أعمق نطلب الكود المصدري أو بناءً قابلاً للتنقيح (debuggable)، ووثائق الواجهة الخلفية. ونتّفق على العمق — الصندوق الأسود أو الرمادي أو الأبيض — قبل أن نبدأ.

هل تختبرون الواجهة الخلفية (API) أيضاً؟

يركّز هذا التقييم على التطبيق على الجهاز وأمن اتصالاته. وإذا أردتم اختبار الواجهة الخلفية (API) من طرف إلى طرف إلى جانب التطبيق، فإنّ تقييمنا المجمَّع للجوّال والـ API يغطّي الاثنين والتكامل بينهما.

هل يجري الاختبار على بيئة الإنتاج أم على بيئة staging؟

نفضّل واجهة خلفية staging ببيانات تمثيلية كي لا يتأثّر مستخدمو الإنتاج وسجلّاته أبداً. وحيث يتعيّن إجراء اختبار على الإنتاج، نتّفق على الحدود مسبقاً ونتجنّب أيّ إجراء متلِف.

إذا كان الهاتف مقفلاً، فهل يُعدّ التخزين المحلي غير الآمن خطراً فعلاً؟

قد يكون كذلك. فالجهاز يُفقد أو يُشارَك أو يُنسخ احتياطياً أو تُفتح صلاحيات جذره، والبيانات المكتوبة غير مشفَّرة — في التفضيلات أو قاعدة البيانات أو السجلّات أو التخزين الخارجي — تصبح قابلة للقراءة لتطبيق آخر أو لمن يحمل الجهاز. نتحقّق ممّا هو مخزَّن، وما إذا كان تخزينه ضرورياً، وما إذا كان محميّاً.

كيف تُحدَّد درجة خطورة النتائج؟

تحصل كلّ نتيجة على درجة CVSS كأساس مشترك، تُعدَّل بحسب الأثر الفعلي في تطبيقكم — ما الذي يبلغه المهاجم، وبأيّ سهولة، وأيّ بيانات أو حسابات في خطر. ولهذا قد تُرتَّب مشكلتان لهما الدرجة نفسها على CVSS بأولويتين مختلفتين.

هل يجب أن يكون التطبيق منشوراً على Play Store؟

لا. نختبر البناء الذي تعطوننا إيّاه، سواء أكان منشوراً أم في اختبار داخلي أم مرشَّحاً للإصدار. وعادةً ما يكون الاختبار قبل الإصدار الوقت الأفضل، لأنّ الإصلاحات تُطبَّق قبل وصول مستخدميكم.

هل تُجرى إعادة الاختبار بعد المعالجة؟

نعم — بعد معالجتكم، نعيد اختبار النتائج المُبلَّغة للتأكّد من ثبات كلّ إصلاح. وتعتمد المدّة على حجم التطبيق وتعقيده، ونقدّم تقديراً محدّداً بعد تحديد النطاق.

هل أنتم مستعدون للبدء؟
تواصلوا مع فريقنا لمناقشة احتياجات تقييم الأمان لديكم