الأمن في Cordova
يتضمن الدليل التالي بعض أفضل ممارسات الأمان التي يجب مراعاتها عند تطوير تطبيقات Cordova. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملاً. إذا كنت تعتقد أنه يمكنك المساهمة في هذا الدليل، فلا تتردد في تقديم مشكلة في تعقب الأخطاء في كوردوفا تحت "Documentation". تم تصميم هذا الدليل ليكون قابلاً للتطبيق على جميع منصات Cordova، ولكن سيتم الإشارة إلى الممارسات الخاصة بمنصات معينة.
يناقش هذا الدليل المواضيع التالية:
- اللوائح البيضاء (Whitelist )
- الإطارات الذكية (Iframes) وآلية تعريف الاستدعاء (Callback Id Mechanism)
- تثبيت الشهادة (Certificate Pinning)
- شهادات موقعة ذاتيا (Self-signed Certificates)
- تخزين مشفر (Encrypted storage)
- نصائح عامة
- مقالات ومصادر
اللائحة البيضاء
قراءة وفهم [../whitelist/index.html Whitelist Guide]
لا تعمل اللوائح البيضاء للنطاقات على الواجهة البرمجية لأندرويد 10 وما دونه، و WP8 للإطارات الذكية (iframe) والكائن XMLHttpRequest. هذا يعني أن المهاجم يمكنه تحميل أي نطاق في إطار ذكي وأي نص برمجي في تلك الصفحة داخل ذلك الإطار يمكنه الوصول مباشرةً إلى كائنات JavaScript في Cordova وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بعين الاعتبار عند إنشاء تطبيقات لهذه المنصات. وهذا يعني التأكد من استهدافك لواجهة برمجة لأندرويد من الإصدار العاشر فما فوق، وأن تتجنب قد الإمكان استخدام الإطارات الذكية لتحميل المحتويات الخارجية - استخدم الإضافة inAppBrowser أو إضافات الطرف الثالث الأخرى.
الإطارات الذكية وآلية تعريف الاستدعاء Iframes and Callback Id Mechanism
إذا تم عرض المحتوى في إطار ذكي من نطاق من اللائحة البيضاء (whiteliste)، فسيكون لذلك النطاق حق الوصول إلى جسر Cordova الأولي (native Cordova bridge). وهذا يعني أنه إذا أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرضت تلك الإعلانات داخل إطار ذكي، فمن المحتمل أن يستطيع أحد الإعلانات الخبيثة الخروج من الإطار الذكي ويفعل أشياء ضارة. ولهذا السبب، يجب ألا تستخدم عمومًا الإطارات الذكية إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي. لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. لاحظ أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات الذكية.
تثبيت الشهادة
لا تدعم Cordova تثبيت الشهادة بشكل فعلي. العائق الرئيسي أمام هذا هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات SSL لإجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندروبد في Java باستخدام JSSE، فإن طريقة المعرض webview على أندرويد مكتوب بلغة C++، ويتم التعامل مع اتصالات الخادم من خلال webview، لذلك لا يمكن استخدام Java و JSSE هناك.) نظرًا لأن Cordova تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإن عدم وجود إمكانية في منصة رئيسية هو ثغرة في هذا التناسق.
هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (fingerprint) هو القيمة المتوقعة عند بدء تشغيل التطبيق، أو في أوقات مختلفة أخرى أثناء عمر تطبيقك. هناك عدة إضافات متاحة يمكنها القيام بذلك. لكن تذكر أن هذا لا يكافئ تثبيت الشهادة الحقيقي، الذي يتحقق تلقائيًا من القيمة المتوقعة عند كل عملية اتصال بالخادم.
هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (يعني غياب طلبيات XHR / AJAX التقليدية، وما إلى ذلك).
الشهادات الموقعة ذاتيا (Self-signed Certificates)
لا ينصح باستخدام الشهادات الموقعة ذاتيا على خادمك. إن أردت استخدام SSL، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة بشكل صحيح من قِبل مرجع موثوق CA (certificate authority). عدم القدرة على القيام بالتثبيت الحقيقي للشهادة يجعل هذا مهمًا.
والسبب هو أن قبول الشهادات الموقعة ذاتيًا يتجاوز سلسلة عمليات التحقق من صحة الشهادة، ما قد يؤدي إلى اعتبار أي شهادة خادم صالحة من قبل الجهاز. هذا يجعل الاتصال عرضة لهجمات الوسطاء الخفيين (man-in-the-middle attacks). لم يعد من اليسير على المخترقين اعتراض وقراءة جميع الاتصالات بين الجهاز والخادم فحسب، بل صاروا أيضًا قادرين تعديل والعبث بتلك الاتصالات. لن يعلم الجهاز أبداً يحدوث هذا لأنه لا يتحقق من أن شهادة الخادم موقعة من قبل مرجع موثوق به (trusted CA). لا يوجد لدى الجهاز أي طريقة للتثبت من أنه يتعامل مع الخادم الذي يتوقعه. نظرًا لسهولة القيام بهجوم الوسيط الخفي (man-in-the-middle)، فإن قبول شهادات موقعة ذاتيًا أفضل بقليل وحسب من إجراء البروتوكول http بدلاً من https على شبكة غير موثوق بها. صحيح أن المعلومات ستكون مشفرة، ولكن يمكن للوسيط الخفي (man-in-the-middle) تحديد مفتاح تشفيرها، وإذا سيكون قادرًا على الوصول إلى كل شيء، لذا فإن التشفير غير ذي جدوى إلا اتُجاه المراقبين السلبيين (passive observers). يثق المستخدمون بأن بروتوكول طبقة المقابس الآمنة (SSL) آمنة، والمفارقة أن هذا من شأنه أن يجعلها غير آمنة، وبالتالي يصبح استخدام طبقة المقابس الآمنة مضللاً. إن كانت ستستخدم في شبكة موثوقة (مثلا في إطار شبكة مؤسسية خاضعة للرقابة)، فلا تزال الشهادات الموقعة ذاتيا غير موصى بها. هناك توصيتان عليك مراعاتهما إن كنت في شبكة موثوق بها، الأولى هي استخدام البروتوكول http، لأن الشبكة نفسها موثوق بها، والثانية هي الحصول على شهادة موقعة من مرجع موثوق CA (وليس موقعة ذاتيًا). إما أن الشبكة موثوقة، أو أنها ليست كذلك.
المبادئ الموضحة هنا ليست مقصورة على Cordova، بل هي تنطبق على جميع الاتصالات بين العميل والخادم.
عند تشغيل Cordova على أندرويد، فإن استخدام android:debuggable="true" في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة على الشهادات الموقعة ذاتيا. لذلك يمكنك استخدام الشهادات الموقعة ذاتياً في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. فمن المفترض استخدامه حصرًا أثناء مرحلة التطوير.
التخزين المشفر
(يحدد لاحقا)
نصائح عامة
لا تستخدم الإصدار Android Gingerbread
- قم بتعيين مستوى min-target-sdk غند مستوى أعلى من 10. API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، ولذلك لا يوصي به فريق Cordova.
- لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو أحد منصات الهاتف الأكثر عرضة للاستهداف http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/.
- لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread أو ما دونه. هذا يعني أن المهاجم يمكنه تحميل شفرة خبيثة في الإطار الذكي (iframe) الذي سيكون قادرًا على الوصول إلى جميع واجهات Cordova البرمجية، ويمكنه استخدام ذلك لسرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام ذات الأسعار الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى.
استخدم InAppBrowser للوصلات الخارجية
- استخدم InAppBrowser عند فتح روابط لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن InAppBrowser ستستخدم ميزات الأمان الأصلية للمتصفح، ولن يمنح الموقع إمكانية الوصول إلى بيئة Cordova. حتى لو كنت تثق بموقع الطرف الثالث وقمت بتضمينه مباشرة في تطبيقك، فيمكن لذلك الموقع أن يرتبط بمحتوى من موقع ضار.
تحقق من صحة جميع مدخلات المستخدم
- تحقق من صحة أي مدخلات يقبلها تطبيقك دائمًا. يتضمن ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لأن المهاجمين يمكنهم العبث بأصول HTML و JS خاصتك (إما عن طريق عكس ترجمة (decompiling) التطبيق أو استخدام أدوات تصحيح الأخطاء مثل أداة chrome://inspect)، يجب إجراء عملية التحقق هذه على الخادم أيضًا، خاصة قبل تسليم البيانات إلى خدمة خلفية (backend service).
- هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (backend service).
لا تخزن البيانات الحساسة
- إذا تم تخزين أسماء المستخدمين وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن المحتمل أن تُسترد لاحقًا من قبل مستخدم أو تطبيق غير مصرح به.
لا تستخدم eval() إلا إذا كنت تعرف ما تفعله
- لطالما أسيئ استخدام دالة الجافاسكريبت eval() . إن استخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (njection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية.
لا تفترض أبدًا أن شيفرتك المصدرية آمنة
- يتم بناء تطبيقات Cordova من أصول (ملفات) HTML وجافا سكريبت، والتي تُحزم في حاويات أصلية (native containers)، لذلك عليك ألا تعتبر شيفرتك آمنة أبدًا. من الممكن إجراء هندسة عكسية على تطبيقات Cordova.
انظر أيضًا
HTML5 Security cheat sheet, detailing how to secure your HTML5 application Phonegap's article on device security, such as using encrypted data Whitepaper about well known security flaws in Webview based hybrid applications