الأمان في التطوير المحمول: ما هو، ما هي التهديدات وكيفية الدفاع

التهديدات الرئيسية: OWASP Mobile Top 10

ما هو OWASP Mobile Top 10؟

OWASP (Open Web Application Security Project) هي منظمة غير ربحية تنشر تصنيفًا لأخطر ثغرات الأمان المحمول. OWASP Mobile Top 10 هي قائمة تساعد المطورين على فهم ما يجب التركيز عليه أولاً. في إصدار 2024، تتصدر المشكلات المتعلقة بالتخزين غير الآمن والمصادقة الضعيفة والاتصال الشبكي غير الآمن التصنيف.

M1: تخزين البيانات غير الآمن — المشكلة الأكثر شيوعًا: تبقى كلمات المرور والرموز والبيانات الشخصية في SharedPreferences أو NSUserDefaults أو ملفات محلية دون تشفير. M2: المصادقة الضعيفة — عدم وجود تحقق من جانب الخادم، كلمات مرور ضعيفة. M3: الاتصال الشبكي غير الآمن — عدم وجود HTTPS أو تحقق غير صحيح من شهادة SSL. يرتبط M4 و M5 بالتشفير والاستخدام غير الصحيح لواجهة API.

M6: التفويض غير الآمن — يمكن للمستخدم الوصول إلى بيانات مستخدم آخر عن طريق استبدال معرف في طلب. M7: حقن الكود (SQL Injection، XSS). M8: التلاعب بالتطبيق — إعادة التغليف، استبدال الكود. M9 و M10 — تسرب البيانات من خلال مكتبات الطرف الثالث والهندسة العكسية. لكل من هذه التهديدات توجد تدابير مضادة مثبتة، وفي IT Sectr نطبقها في جميع المشاريع منذ عام 2017.

هجمات الوسيط (MITM)

هجوم MITM يحدث عندما يعترض المهاجم حركة المرور بين التطبيق والخادم. هذا ممكن من خلال انتحال DNS أو ARP spoofing أو الاتصال بشبكة Wi-Fi غير آمنة. تُستخدم شهادات SSL/TLS و Certificate Pinning للحماية.

Certificate Pinning هي آلية يتحقق فيها التطبيق من أن شهادة الخادم تطابق شهادة مخزنة مسبقًا في كود التطبيق. حتى إذا قام المهاجم باستبدال الشهادة عبر وكيل (مثل Burp Suite)، سيرفض التطبيق الاتصال. هناك نوعان من Pinning: Public Key Pinning و Certificate Hash Pinning.

التشفير والهاش: AES، RSA، SSL/TLS

التشفير المتماثل: AES

AES (Advanced Encryption Standard) هو خوارزمية تشفير متماثل، أساس أمان البيانات على الجهاز. يستخدم AES نفس المفتاح لتشفير وفك تشفير البيانات. يدعم AES مفاتيح بطول 128 أو 192 أو 256 بت. في التطوير المحمول، يُستخدم AES-256 لتشفير البيانات على الجهاز: الملفات، ذاكرة التخزين المؤقت، السجلات في قاعدة البيانات المحلية.

أوضاع AES: GCM (موصى به) — يوفر مصادقة البيانات، CBC — الوضع الأساسي مع سلسلة الكتل، ECB — غير آمن، لا تستخدمه. لنظام iOS، AES متاح عبر CommonCrypto (CCOptions)، لنظام Android — عبر Cipher في Java Cryptography Architecture (JCA). مهم: يجب أبدًا تخزين مفتاح التشفير في كود التطبيق — استخدم Keychain/Keystore.

التشفير غير المتماثل: RSA — يستخدم زوجًا من المفاتيح (عام وخاص). يُستخدم RSA لتشفير كميات صغيرة من البيانات — عادة لتبادل مفتاح متماثل بين العميل والخادم. الحد الأدنى لطول مفتاح RSA هو 2048 بت (4096 موصى به). على iOS، RSA متاح عبر Security Framework (SecKeyCreateRandomKey)، على Android — عبر KeyPairGenerator في Android Keystore.

الهاش و SSL/TLS

الهاش (SHA-256، SHA-3) هو تحويل غير قابل للعكس للبيانات إلى سلسلة بطول ثابت. تُستخدم الهاشات للتحقق من سلامة البيانات وتخزين كلمات المرور. لكلمات المرور، استخدم обязательно bcrypt أو scrypt أو Argon2 — SHA-256 العادي عرضة لهجمات جداول قوس قزح. SSL/TLS هو بروتوكول لتشفير حركة مرور الشبكة بين العميل والخادم. المعيار الحديث هو TLS 1.3، الذي يوفر السرية التامة للتوجيه (PFS).

TLS 1.3 أسرع من سابقيه: المصافحة تستغرق جولة واحدة بدلاً من اثنتين. على Android، يتم تكوين الحد الأدنى لإصدار TLS عبر SSLSocket، على iOS — عبر ATS (App Transport Security)، الذي يتطلب افتراضيًا TLS 1.2 أو أعلى. يمكن تعطيل ATS فقط لنطاقات محددة مع التبرير.

التخزين الآمن: Keychain و Keystore

iOS: Keychain

Keychain (سلسلة المفاتيح) هو مخزن آمن في iOS / macOS لكلمات المرور ومفاتيح التشفير والشهادات والرموز. يتم تشفير البيانات في Keychain بمفتاح جهاز فريد لكل جهاز. يتم التحكم في الوصول إلى Keychain عبر Security Framework (SecItemAdd، SecItemCopyMatching). يتم قفل Keychain تلقائيًا عند قفل الجهاز ويتم تشفيره باستخدام Secure Enclave.

Android: Keystore

Android Keystore هو مخزن نظام للمفاتيح التشفيرية، معزول عن التطبيق. بدءًا من Android 6.0 (API 23)، يستخدم Keystore دعم الأجهزة (TEE — Trusted Execution Environment) على الأجهزة المزودة بشريحة أمان. لا تغادر المفاتيح في Keystore المنطقة الآمنة أبدًا — يتلقى التطبيق فقط مقبضًا لعمليات التشفير والتوقيع.

SharedPreferences و NSUserDefaults غير مصممتين لتخزين البيانات الحساسة — يخزنان المعلومات بنص عادي. لحماية البيانات، استخدم EncryptedSharedPreferences (Android) أو قم بتشفير البيانات قبل حفظها في UserDefaults (iOS). في IT Sectr، نستخدم دائمًا Keychain و Keystore لرموز الوصول وكلمات المرور.

المصادقة: OAuth 2.0، JWT والقياسات الحيوية

OAuth 2.0 و OpenID Connect

OAuth 2.0 هو بروتوكول تفويض مفوض يوفر وصولاً آمنًا إلى موارد المستخدم دون نقل كلمة المرور. في التطبيقات المحمولة، الأكثر استخدامًا هو Authorization Code Flow مع PKCE (Proof Key for Code Exchange). يمنع PKCE اعتراض رمز التفويض — شرط إلزامي للتطبيقات المحمولة.

OpenID Connect (OIDC) هو امتداد فوق OAuth 2.0 لمصادقة المستخدم. يضيف OIDC رمز مميز (ID Token) بتنسيق JWT يحتوي على معلومات المستخدم (الاسم، البريد الإلكتروني، المعرف). يتدفق OAuth 2.0 + OIDC يشمل: إعادة توجيه المستخدم إلى صفحة تسجيل الدخول، الحصول على رمز التفويض، استبدال الرمز برموز (access + refresh + id)، استخدام رمز الوصول لطلبات API.

JWT: رموز الوصول والتحديث والجلسة

JWT (JSON Web Token) هو تنسيق رمز مضغوط وآمن لعناوين URL يحتوي على مطالبات بتنسيق JSON. يتكون JWT من ثلاثة أجزاء: الرأس (النوع وخوارزمية التوقيع)، الحمولة (البيانات) والتوقيع. رمز الوصول هو رمز قصير العمر (15-60 دقيقة) للوصول إلى API. رمز التحديث هو رمز طويل العمر (أيام/أسابيع) للحصول على رمز وصول جديد دون إعادة تسجيل الدخول.

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

المصادقة البيومترية

Face ID و Touch ID على iOS، مصادقة بصمة الإصبع على Android — طرق مصادقة بيومترية تستخدم الخصائص الفيزيائية الفريدة للمستخدم. على iOS، تعمل القياسات الحيوية عبر LocalAuthentication (LAContext)، على Android — عبر BiometricPrompt (Android 9+) أو FingerprintManager (قديم). تُستخدم القياسات الحيوية لفتح التطبيق وتأكيد المدفوعات والوصول إلى البيانات المحمية.

فروق دقيقة مهمة: القياسات الحيوية هي تجربة مستخدم مريحة، ولكنها ليست بديلاً عن مصادقة الخادم. بعد التحقق البيومتري الناجح، يجب على التطبيق الحصول على رمز وصول من الخادم. على Android، تأكد من التحقق من أن الجهاز يستخدم قياسات حيوية من الفئة 3 (قوية)، وليس فقط التعرف على الوجه بالكاميرا (الفئة 1).

حماية الكود: ProGuard، R8 و Root Detection

التعقيد: ProGuard و R8

ProGuard هو أداة لتعقيد وضغط وتحسين كود Java البايت لنظام Android، مما يزيد من أمان الكود ضد الهندسة العكسية. R8 هو خليفته، مدمج في Gradle منذ Android Studio 3.4. يقوم R8 بأربع مهام: الضغط (يزيل الفئات والطرق غير المستخدمة)، التحسين (يدرج الطرق، يبسط الكود)، التعقيد (يعيد تسمية الفئات والطرق إلى أسماء قصيرة) والتحقق المسبق (فحص الكود البايت).

DexGuard هو إصدار تجاري من ProGuard مع حماية محسّنة: تشفير السلاسل، تعقيد الموارد، حماية من إعادة التغليف، التحكم في سلامة APK. لمعظم المشاريع، R8 كافٍ، ولكن للتطبيقات المالية والمصرفية، يوفر DexGuard طبقة إضافية من الأمان. يتم تمكين R8 عبر build.gradle: minifyEnabled = true و proguardFiles.

كشف الجذر و Jailbreak

Root Detection (Android) و Jailbreak Detection (iOS) هما آليتان تتحققان مما إذا كانت صلاحيات المستخدم الفائق قد تم الحصول عليها على الجهاز. على الأجهزة المخترقة، يمكن قراءة ذاكرة العملية واعتراض حركة المرور واستبدال الكود. للتحقق على Android، يُستخدم وجود ملف SU الثنائي ومفاتيح توقيع الاختبار وأعلام البناء غير القياسية.

RASP (Runtime Application Self-Protection) هي تقنية تحمي التطبيق أثناء التنفيذ. يكتشف RASP محاولات التصحيح وإعادة التغليف وحقن الكود ويُنهي التطبيق عند اكتشاف التهديدات. أمثلة على حلول RASP: Dexter، Guardsquare، Promon. يعمل RASP في وقت التشغيل ويتفاعل مع الحالات الشاذة — على عكس التعقيد الثابت، الذي يحمي الكود قبل التنفيذ.

الهندسة العكسية هي عملية استعادة الكود المصدري من تطبيق مُجمَّع. أدوات: JADX (مفكك APK)، Ghidra، IDA Pro، Hopper. الحماية من الهندسة العكسية هي مزيج من التعقيد وتشفير السلاسل والتحقق من السلامة و Root Detection. لا توجد حماية كاملة — الهدف هو جعل الهندسة العكسية مكلفة بما يكفي للمهاجم.