دراسة حالة: تدقيق أمني لتطبيق مصرفي وفق OWASP وMobSF

تبيع معظم الوكالات الأمان كصفة. أما دراسة الحالة هذه فهي سجل موثّق: بنك تجزئة حقيقي، ودرجة حقيقية من أداة فحص، و48 ثغرة مُقيَّمة، و124 مهمة، وقائمة صادقة بما لا يزال مفتوحًا.

بُني تطبيق Android الخاص بالبنك على حزمة SDK مصرفية بعلامة بيضاء (white-label). وحين أعاد فحص البنك نفسه درجة أمان MobSF تبلغ 48 من 100، لم يكن السؤال كيف نرفع الرقم فحسب، بل ماذا يعني الرقم فعلًا، وأي الثغرات حقيقية، وكيف نصلحها بطريقة يستطيع فريق الأمن في البنك التحقق منها.

في هذا المقال نستعرض كيف أُجري التدقيق، وما الذي شملته المعالجة، وكيف جرى التحقق من الإصلاحات، وما الذي لا يزال مفتوحًا.

نقطة الانطلاق

درجة 48/100 تبدو مقلقة، لكن الدرجة الخام وحدها لا تقول الكثير. فقبل أي إصلاح، كان علينا الإجابة عن ثلاثة أسئلة:

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

📌 فكرة أساسية:

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

كيف أُجري التدقيق

المرحلة 1: إعادة إنتاج درجة أداة الفحص

أعدنا بناء الفحص وأعدنا إنتاج نتيجة البنك. ثم قسّمنا كل نقطة خسرها التطبيق إلى فئات. وكانت النتيجة التي فاجأت البنك أكثر من غيرها: 6–7 نقاط من أصل 52 نقطة مفقودة جاءت فقط من نوع البناء، إذ كان الفحص قد أُجري على نسخة تصحيح (debug) بدلًا من نسخة الإصدار (release) التي يثبّتها المستخدمون فعلًا. كما تبيّن أن فحصين وصفتهما الأداة بأنهما آمنان كانا نتيجتين إيجابيتين كاذبتين.

المرحلة 2: تدقيق يدوي وفق OWASP Mobile Top 10 (2024)

راجعنا التطبيق فئةً فئةً وفق OWASP Mobile Top 10 (2024)، من الاستخدام غير السليم لبيانات الاعتماد (M1) وأمن سلسلة التوريد (M2) وصولًا إلى التخزين غير الآمن للبيانات (M9) والتشفير غير الكافي (M10). وحصلت كل ثغرة على درجة CVSS، ليتمكن البنك من ترتيب الأولويات وفق درجة الخطورة لا وفق مدى إثارة النتيجة للقلق.

النتيجة: 48 ثغرة مُقيَّمة وفق CVSS.

المرحلة 3: خطة معالجة محسوبة التكلفة

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

المرحلة 4: المعالجة وتعزيز الحماية

إلى جانب إصلاح النتائج، بنينا واختبرنا مجموعة من آليات الحماية أثناء التشغيل ومكافحة الاستغلال، منها:

الحماية من التراكب (overlay) على ثلاث طبقات، إضافة إلى مصنِّف لكشف إساءة استخدام خدمات إمكانية الوصول.
تسجيل الدخول بالبصمة مربوطًا بـCryptoObject، بحيث لا يستطيع استدعاء (callback) تعرّض للاعتراض تزييف تسجيل دخول ناجح.
كشف الروت وFrida والمحاكيات، مع 35 اختبارًا لكشف المحاكيات بالقيم الدقيقة ودون أي إنذارات كاذبة على أجهزة Chromebook.
منع إعادة التغليف عبر فحص لشهادة التوقيع وفحص لمصدر التثبيت.
مسح الحافظة بعد 60 ثانية من نسخ القيم الحساسة.
TLS 1.3 فقط لحركة الشبكة.
تشفير المغلّف (Envelope Encryption) للبيانات المحلية بدلًا من SQLCipher، ما وفّر 6.5 ميغابايت من الشيفرة الأصلية مقابل نحو 1 مللي ثانية لكل شاشة.

كيف جرى التحقق من الإصلاحات

الإصلاحات التي لم يختبرها إلا المطوّر ادعاءات لا أدلة. لذلك جرى التحقق على طبقتين.

حزمة اختبارات أمان مستقلة لضمان الجودة

بنى فريق ضمان الجودة حزمة للتحقق الأمني تضم 79 فحصًا مؤتمتًا تغطي 45 تذكرة أمنية. ويؤكد كل فحص أن آلية حماية محددة تعمل على نسخة حقيقية.

اختبار الاختبارات

ثم اختبرنا حزمة ضمان الجودة نفسها باستخدام اختبار الطفرات (Mutation Testing): تعطيل آليات الحماية الأمنية عن عمد في نسخ اختبارية والتأكد من أن الفحوص تلتقط كل عطل. والتقطت أداة التشغيل كل الطفرات. والأهم بالقدر نفسه أن 13 من تلك الطفرات كانت قد نجت من اختبارات المطورين أنفسهم، وهي بالضبط الثغرات التي وُجد الفحص المستقل لاكتشافها.

أدلة سلسلة التوريد في CI

يُشحن كل إصدار الآن مع CycloneDX SBOM، وتُفحص التبعيات باستخدام OWASP Dependency-Check. وقد أسفر الفحص الأول عن 1,388 تطابقًا خامًا مع ثغرات CVE. وجرى فرز كل واحد منها وإخماده مع سبب مكتوب ومؤرَّخ، ولم يتبيّن أن أيًّا منها ثغرة حقيقية في ملف APK الخاص بالإصدار.

النتائج في لمحة

البند	النتيجة
درجة MobSF عند الانطلاق	48/100، أُعيد إنتاجها
نقاط يفسّرها نوع البناء وحده	6–7 من 52
علامات «آمن» من أداة الفحص تبيّن أنها كاذبة	2
ثغرات مُقيَّمة وفق CVSS	48
مهام معالجة مُتتبَّعة	124
فحوص أمان ضمان الجودة	79 فحصًا تغطي 45 تذكرة
تطابقات CVE خام جرى فرزها	1,388 ← 0 حقيقية
المدة	نحو تسعة أسابيع

ما الذي لا يزال مفتوحًا

ننشر الثغرات المتبقية مع النتائج، لأن هذا ما يجعل البقية جديرة بالتصديق:

لا إعادة تقييم نهائية ولا اختبار اختراق خارجي حتى الآن. لا ندّعي الحصول على درجة MobSF نهائية، ولا اجتياز اختبار اختراق، ولا التوافق الكامل مع OWASP MASVS.
تثبيت الشهادات (Certificate Pinning) جاهز وينتظر سياسة تدوير المفاتيح لدى البنك قبل تفعيله.
فحص التبعيات يُبلغ لكنه لا يحظر بعدُ الإصدارات عند وجود نتائج عالية الخطورة.

خدمة Mobile Security Teardown من Mobian

أصبح هذا المشروع القالب الذي بُنيت عليه خدمتنا Mobile Security Teardown: أسبوعان، بسعر ثابت. نعيد إنتاج درجة أداة الفحص لديك، ونجري تدقيقًا يدويًا وفق OWASP Mobile Top 10 (2024)، ونقيّم كل ثغرة وفق CVSS، ونسلّمك خطة معالجة محسوبة التكلفة يستطيع فريقك، أو فريقنا، تنفيذها.

في Mobian، لسنا شركة امتثال، ولن نقول لك إن التدقيق يجعلك متوافقًا. ما نقدّمه هو أدلة يستطيع مدققك تتبّعها، وصولًا إلى الملف والسطر.

الخلاصة

أخبرت درجة MobSF البالغة 48/100 البنك بأن هناك خللًا ما، لكنها لم تخبره بماهيته. وقد حوّلت إعادة إنتاج الدرجة، والتدقيق اليدوي وفق OWASP، وتقييم كل ثغرة، والتحقق من كل إصلاح، رقمًا واحدًا مقلقًا إلى 124 مهمة لكلٍّ منها مسؤول ويمكن تتبّعها. إذا كانت جهة ما، سواء أكانت بنكًا شريكًا أم مدققًا أم جهة تنظيمية، قد وجدت بالفعل مشكلة في تطبيق الجوال الخاص بك، فمن هنا تبدأ.

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

ماذا شمل التدقيق الأمني؟

أربعة أمور: إعادة إنتاج فحص MobSF الذي أجراه البنك بنفسه، وتدقيق يدوي لتطبيق Android يغطي الفئات العشر كلها في OWASP Mobile Top 10 (2024)، ودرجة CVSS لكل ثغرة مكتشفة، وخطة معالجة محسوبة التكلفة. وتلت ذلك المعالجة والتحقق المستقل من فريق ضمان الجودة ضمن المشروع نفسه.

هل اجتاز التطبيق اختبار اختراق بعد الإصلاحات؟

لا ندّعي ذلك. فلم يُجرَ بعدُ أي اختبار اختراق خارجي ولا أي إعادة تقييم نهائية بأداة MobSF. ما يمكننا إظهاره هو سجل مؤرَّخ ومُرقَّم: 48 ثغرة مُقيَّمة، و124 مهمة مُتتبَّعة، وحزمة لضمان الجودة تتحقق من الإصلاحات وجرى اختبارها هي نفسها على نسخ معطّلة عن عمد.

هل تكفي درجة MobSF للحكم على أمان التطبيق؟

لا. في هذا المشروع، جاءت 6–7 نقاط من أصل 52 نقطة مفقودة فقط من فحص نسخة تصحيح (debug) بدلًا من نسخة الإصدار (release)، وتبيّن أن فحصين وصفتهما الأداة بأنهما آمنان كانا نتيجتين إيجابيتين كاذبتين. الدرجة نقطة انطلاق لتدقيق يدوي، لا حكم نهائي.

هل يجعل هذا العمل التطبيق متوافقًا مع DORA أو غيرها من اللوائح؟

Mobian ليست شركة امتثال، والتدقيق وحده لا يجعل التطبيق متوافقًا. ما ينتجه التدقيق هو أدلة يستطيع المدقق تتبّعها: نتائج مُقيَّمة، وقرار مكتوب لكل تغيير، ومعالجة على مستوى الملفات، ونتائج تحقق مستقلة من ضمان الجودة. وفرق الامتثال والفرق القانونية لديك هي التي تقرر ما الذي تغطيه هذه الأدلة.

هل يمكن لآليات الحماية نفسها أن تحمي تطبيقات العملات المشفّرة أو الألعاب؟

كثير منها، نعم. فالحماية من التراكب (overlay)، وكشف إساءة استخدام خدمات إمكانية الوصول، وكشف الاعتراض والمحاكيات، وفحوص منع إعادة التغليف، كلها تستهدف أنماط استغلال متشابهة في التطبيقات المالية. لم نبنِ ميزات خاصة بقطاعات بعينها مثل حفظ المفاتيح أو تحديد الموقع الجغرافي المعتمد، ونقول ذلك بوضوح منذ البداية.

دراسة حالة: من درجة MobSF 48/100 إلى 124 إصلاحًا أمنيًا مُتتبَّعًا في تسعة أسابيع