اختبار أمان تطبيقات الجوال

لماذا يهم

الشركة لا تتحكم في الهاتف. فقد يُفقد أو تُكسر حمايته (rooted) فيُفتح الوصول الكامل إلى نظامه، أو يُستعاد من نسخة احتياطية، ويتصل بشبكات Wi-Fi عامة، ويستطيع أي شخص تفكيك حزمة التطبيق. فكل ما يخزّنه التطبيق أو يرسله أو يقبله من التطبيقات الأخرى مكشوف، ورمز (token) واحد مسرَّب قد يعني الاستيلاء على حساب.

ومعظم فحوص الخط الأول لا تحتاج إلى مهارات اختراق، ومعرفة قواعد المنصة تمنع التقارير الخاطئة: فالتطبيق الذي يرفض الاتصال عبر الوكيل (proxy) الخاص بك كثيراً ما يفعل بالضبط ما يجب.

مجموعات الضوابط في MASVS

يوزّع MASVS ضوابطه على ثماني مجموعات ضوابط (control groups)، يبدأ اسم كل منها بالبادئة MASVS-، ويشرح MASTG كيف تُختبر على Android وiOS.

يختبر هذا الدرس مجموعات التخزين والشبكة والمنصة، حيث تكشف أدوات المختبِر المعتادة عيوباً حقيقية. والمجموعات الثماني كلها:

• MASVS-STORAGE: البيانات الحساسة على الجهاز محمية ولا تتسرب.
• MASVS-CRYPTO: خوارزميات قوية، ولا مفاتيح مكتوبة داخل التطبيق.
• MASVS-AUTH: تسجيل الدخول والجلسات والتفويض يفرضها الخادم الخلفي؛ والتحقق المحلي مثل القياسات الحيوية (biometrics) يُنفَّذ بأمان.
• MASVS-NETWORK: TLS مع تحقق سليم من الشهادات، وتثبيت الشهادة حيث تستدعيه المخاطر.
• MASVS-PLATFORM: استعمال آمن للروابط والمكوّنات وWebView والشاشة.
• MASVS-CODE: التحقق من المدخلات غير الموثوقة؛ ولا مكوّنات ذات ثغرات معروفة.
• MASVS-RESILIENCE: مقاومة الهندسة العكسية والعبث حيث تستدعي المخاطر ذلك.
• MASVS-PRIVACY: البيانات التي يحتاجها التطبيق فقط، يراها المستخدم ويتحكم فيها.

التخزين المحلي: ما يبقى على الجهاز

يحفظ التطبيق بياناته في بيئته المعزولة (sandbox): ملفات التفضيلات في shared_prefs وقواعد بيانات SQLite والملفات على Android، وUserDefaults والملفات وقواعد البيانات على iOS. والبيئة المعزولة تمنع التطبيقات الأخرى، لكنها لا تمنع من يملك هاتفاً مكسور الحماية أو نسخة احتياطية أو نسخة قابلة للتصحيح (debuggable)، وهي نسخة تصحيح تسمح لأدوات مثل run-as بالوصول إلى ملفات التطبيق، أما نسخ الإصدار فليست قابلة للتصحيح. وتتسرب البيانات أيضاً إلى السجلات (logs) والحافظة ولقطة مبدّل التطبيقات.

واختبار MASVS-STORAGE بسيط: البيانات الحساسة لا تُخزَّن إلا عند الحاجة، والأسرار محفوظة في iOS Keychain أو مشفّرة بمفتاح محفوظ في Android Keystore (وهما المخزنان المحميان في المنصتين)، والسجلات خالية من أي شيء حساس، وتسجيل الخروج يحذف بيانات الجلسة. والترميز ليس تشفيراً: سلسلة Base64 أو رمز JWT موقَّع في ملف يقرؤه كل من يحصل على الملف. وعلى نسخة ضمان الجودة (QA build) في Android، انظر بنفسك:

# Debuggable QA build, on a test phone or emulator you may use
adb shell run-as com.example.shop ls shared_prefs databases files
adb shell run-as com.example.shop cat shared_prefs/session.xml
#   <string name="refresh_token">eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOi...</string>
#   ^ a finding: a token in plain text

adb logcat -d | grep -i -E "password|token|bearer|otp"

# Release build: run-as must fail, because the build is not debuggable
adb shell run-as com.example.shop ls

جرّبها: مفكّك ترميز Base64 جرّبها: مفكّك ترميز JWT جرّبها: فاحص انتهاء صلاحية JWT

مثال تطبيقي: قراءة حركة HTTPS لتطبيق Android

لديك إذن كتابي باختبار تطبيق التسوّق الخاص بفريقك مقابل api.staging.shop.example. والوكيل الاعتراضي (intercepting proxy) أداة تقف بين التطبيق والخادم وتعرض كل طلب واستجابة؛ ويشرح درس الوكيل الاعتراضي إعداده بالتفصيل. ونطاقه (scope) هو مجموعة المضيفات المأذون لك باختبارها، فلا تضع في النطاق إلا هذا المضيف. وسجلّه (history) يسرد كل طلب التقطه، فتستطيع أن تجد الطلب لاحقاً، أو ترفقه دليلاً، أو تعيد تشغيله (replay)، أي ترسله إلى الخادم مجدداً. ويعمل الوكيل على حاسوبك، ويستمع على عنوان الحاسوب في شبكة Wi-Fi، مثل 192.168.1.20:8080. ولكي يقرأ الوكيل حركة HTTPS، فإنه ينهي اتصال TLS الخاص بالتطبيق بنفسه ويقدّم للتطبيق شهادة باسم المضيف موقّعة من مرجعه المصدّق (CA) الخاص. لذا تضبط على هاتف اختبار مخصّص هذا العنوان وكيلاً لشبكة Wi-Fi، وتضيف شهادة المرجع المصدّق للوكيل إلى الهاتف كشهادة مستخدم.

يفشل التطبيق الآن في الاتصال، ويسجّل الوكيل أخطاء في مصافحة TLS. هذا هو Android يعمل كما صُمّم: منذ Android 7.0 (مستوى API رقم 24)، لا تثق التطبيقات التي تستهدف هذا المستوى أو أعلى افتراضياً إلا بمراجع النظام المصدّقة، لا بالمراجع التي أضافها المستخدم. والطريقة الآمنة للسماح بها، الظاهرة أدناه، هي كتلة debug-overrides في إعدادات أمان الشبكة (Network Security Configuration): لا تُطبَّق إلا على نسخة قابلة للتصحيح، فتثق نسخة ضمان الجودة بمرجع الوكيل وتحتفظ نسخة الإصدار (release build) بالإعداد الافتراضي. وبعد أن تصبح حركة المرور مقروءة، افحص:

• كل طلب يستخدم HTTPS، بما في ذلك الصور وحزم SDK. والتطبيقات التي تستهدف Android 9 (مستوى API رقم 28) أو أعلى تمنع HTTP الصريح افتراضياً، فنداء http:// الناجح يعني غالباً أن أحداً سمح بالنص الصريح لهذا المضيف: أبلغ عنه.
• الرموز تنتقل في الترويسة Authorization، لا في عنوان URL أبداً، حيث تسجّلها الخوادم.
• بعد تسجيل الخروج، إذا أعدت تشغيل طلب بالرمز القديم فالاستجابة 401 Unauthorized.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <debug-overrides>          <!-- applies only when the app is debuggable -->
    <trust-anchors>
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

<!-- AndroidManifest.xml -->
<application android:networkSecurityConfig="@xml/network_security_config" ...>

جرّبها: محلّل ترويسات HTTP جرّبها: مختبِر مصادقة API

تثبيت الشهادة سلوك متوقع

تثبيت الشهادة (Certificate Pinning)، ويسمّيه MASVS تثبيت الهوية (identity pinning)، يعني أن التطبيق لا يقبل لمضيفات واجهته البرمجية إلا شهادة أو مفتاحاً عاماً أو مرجعاً مصدّقاً معروفاً. وهو يحمي المستخدمين من مرجع مصدّق خبيث أو غير مرغوب على الهاتف، ويحجب الوكيل الخاص بك أيضاً: تفشل المصافحة. وعلى نسخة الإصدار هذه نتيجة ناجحة، لذا فتقرير «التطبيق لا يعمل عبر الوكيل» تقرير خاطئ.

والتثبيت قرار مخاطر يوثّقه الفريق. وحين يطبّق التطبيق تثبيت الشهادة، اختبر السلوك لا التجاوز:

• عبر الوكيل، ترفض النسخة التي تطبّق التثبيت الاتصالَ برسالة خطأ واضحة، بلا انهيار ولا إعادة محاولة عبر HTTP الصريح؛ ومن دون الوكيل تعمل.
• نسخة الإصدار في Android ترفض شهادة المستخدم أصلاً، فهذا الفشل وحده ليس دليلاً على التثبيت؛ اطلب نسخة اختبار تثق بشهادات المستخدم وتُبقي التثبيت مفعّلاً.
• حركة المرور للفحوص الوظيفية تأتي من نسخة ضمان الجودة: افتراضياً لا يطبّق Android التثبيت المعرَّف في إعدادات أمان الشبكة على المراجع المضافة في debug-overrides. أما التثبيت المكتوب في شيفرة التطبيق فيحتاج إلى خيار تعطيل خاص بنسخ التصحيح؛ فاتفق عليه مع المطورين. وتجاوز التثبيت في نسخة الإصدار عمل متخصصين.
• اسأل كيف تُبدَّل المفاتيح المثبَّتة: توصي وثائق Android بإضافة مفتاح احتياطي دائماً، وإلا فتغيير المفتاح على الخادم يقطع اتصال كل نسخة من التطبيق على أجهزة المستخدمين إلى أن يُنشر تحديث للتطبيق.

التفاعل مع المنصة: الروابط والمكوّنات وWebView والشاشة

يغطي MASVS-PLATFORM ما يتبادله التطبيق مع نظام التشغيل والتطبيقات الأخرى. عامِل كل نقطة دخول يصل إليها تطبيق آخر أو صفحة ويب كمدخل غير موثوق؛ والأوامر أدناه تفتح رابطاً عميقاً كما يفعل تطبيق آخر.

• الروابط العميقة (Deep Links): يستطيع أي تطبيق فتح shop://orders/1043 بأي قيمة. الشاشة المحمية تطلب تسجيل الدخول أولاً، والخادم يرفض مع ذلك طلب شراء مستخدم آخر. وروابط Android App Links وiOS Universal Links يُتحقق من ارتباطها بنطاق التطبيق؛ أما المخطط المخصّص مثل shop:// فلا، ويستطيع تطبيق آخر تسجيل المخطط نفسه واستقبال الرابط، لذا يجب ألا يحمل سراً أبداً، كرمز دخول.
• المكوّنات المكشوفة (exported): الأنشطة والخدمات ومستقبِلات البث ومزوّدات المحتوى في Android لا تُكشف إلا إذا احتاجتها تطبيقات أخرى، وعندئذ تتحقق مما تتلقاه.
• WebView لا يحمّل إلا صفحات التطبيق نفسه أو الصفحات المسموح بها، لا عنوان URL مأخوذاً من معامل في رابط.
• الشاشة: الشاشات الحساسة مخفية في معاينة مبدّل التطبيقات، وحقول كلمات المرور مقنّعة.

# Android test device: open a deep link the way another app would
adb shell am start -W -a android.intent.action.VIEW \
  -d "shop://orders/1043" com.example.shop

# iOS simulator
xcrun simctl openurl booted "shop://orders/1043"

أسئلة شائعة

المراجع

• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationمتطلبات OWASP الأمنية لتطبيقات الجوال، مجمّعة في مجالات ضبط مثل التخزين والتشفير والمصادقة والشبكة والتفاعل مع المنصة.
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP Foundationدليل الاختبار المرافق لـ MASVS: تقنيات وحالات اختبار للتحقق من أمان تطبيقات الجوال.
• About App LinksAndroid Developers (Google)روابط App Links في Android: روابط عميقة إلى موقعك يتحقق منها النظام عبر ملف Digital Asset Links (assetlinks.json)، فتفتح التطبيق مباشرةً.
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019منهج ISTQB التخصصي لاختبار تطبيقات الجوال: أنواع التطبيقات وتحديات الأجهزة والمنصات وأنواع الاختبار والأدوات.