إدارة الأمن في كوردوفا

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

تم تصميم هذا الدليل ليُطبّق على جميع منصات كوردوفا؛ الممارسات الخاصة بمنصات معينة سيُشار إليها في موضعها.

اللائحة البيضاء

لا تعمل اللوائح البيضاء (Whitelist) على الواجهة البرمجية لأندرويد 10 (Android API 10) وما دونها، وكذلك ويندوز 8 للإطارات iframe وللكائنات XMLHttpRequest. هذا يعني أن المهاجم يمكنه تحميل نطاق (domain) ما في الإطار iframe، وستكون النصوص البرمجية الموجودة في الصفحة المُحمّلة داخل ذلك الإطار قادرة على الوصول مباشرةً إلى كائنات JavaScript في كوردوفا وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بالحسبان عند إنشاء تطبيقات لهذه المنصات. هذا يعني التأكد من أن واجهات أندرويد البرمجية التي تستهدفها من الإصدار العاشر فما فوق، وأن تتجنب قدر الإمكان استخدام الإطارات iframe لتحميل المحتويات الخارجية؛ استخدم الإضافة inAppBrowser أو إضافات أخرى من طرف ثالث.

الإطارات iframe الذكية وآلية تعريف الاستدعاء

إذا تم عرض المحتوى في إطار iframe ذكي انطلاقًا من نطاق موجود في اللائحة البيضاء، فسيكون لذلك النطاق حق الوصول إلى جسر كوردوفا الأولي (native Cordova bridge). وهذا يعني أنه في حال أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرَضت تلك الإعلانات داخل الإطار iframe الذكي، فمن المحتمل أن يتمكن أحد الإعلانات الخبيثة من الخروج من الإطار الذكي وفعل أشياء ضارة. لهذا السبب، يجب ألا تستخدم الإطارات iframe الذكية عمومًا، إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي.

لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. ولاحظ أيضًا أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات iframe الذكية.

تثبيت الشهادة

لا تدعم كوردوفا تثبيت الشهادة (Certificate Pinning) بشكل فعلي. والعائق الرئيسي أمام ذلك هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات بروتوكول طبقة المقابس الآمنة (SSL) لأجل إجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندرويد في Java باستخدام JSSE، فإنّ المعرض webview على أندرويد مكتوب بلغة C++‎، ويتم التعامل مع اتصالات الخادم من طرف webview، لذلك لا يمكن استخدام Java و JSSE هناك.) نظرًا لأن كوردوفا تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإنَّ عدم وجود إمكانية مهمة كهذه في منصة رئيسية هو ثغرة في هذا التناسق.

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

هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (ما يعني غياب طلبيات XHR/AJAX التقليدية وغيرها).

الشهادات الموقعة ذاتيا

لا ينصح باستخدام الشهادات الموقعة (Self-signed Certificates) ذاتيًّا على خادمك. إن أردت استخدام بروتوكول طبقة المقابس الآمنة (SSL)، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة من قِبل مرجع موثوق (certificate authority). فعدم القدرة على القيام بالتثبيت الحقيقي للشهادة يجعل هذا ضروريًا.

السبب هو أن قبول الشهادات الموقعة ذاتيًا يتجاوز عملية التحقق من سلسلة الشهادة (certificate chain validation) ما قد يؤدي إلى اعتبار أية شهادة خادم صالحة من قبل الجهاز. هذا يجعل الاتصال عرضة لهجمات الوسطاء الخفيين (man-in-the-middle attacks).

لم يعد مُيسّرا للمخترقين اعتراض وقراءة جميع الاتصالات بين الجهاز والخادم فحسب، بل صاروا أيضًا قادرين على تعديل تلك الاتصالات والعبث بها. ولن يعلم الجهاز أبدًا بحدوث ذلك لأنه لا يتحقق من أنّ شهادة الخادم موقعة من قبل مرجع موثوق (trusted CA). لا يوجد لدى الجهاز أي طريقة للتثبت من أنه يتعامل مع الخادم الذي يتوقعه.

نظرًا لسهولة القيام بهجوم الوسيط الخفي (man-in-the-middle)، فإن أفضلية قبول شهادات موقعة ذاتيًا محدودة مقارنة بإجراء البروتوكول http بدلًا من https على شبكة غير موثوق بها. صحيح أن المعلومات ستكون مشفرة، ولكن يمكن للوسيط الخفي (man-in-the-middle) تحديد مفتاح تشفيرها، لذا سيكون قادرًا على الوصول إلى كل شيء؛ بناءً على ذلك، فإن التشفير غير ذي جدوى باستثناء اتجاه المراقبين السلبيين (passive observers).

يثق المستخدمون بأن بروتوكول طبقة المقابس الآمنة (SSL) آمن، إذ هذه الثقة من شأنها أن تجعله غير آمن، وبالتالي يصبح استخدام SSL مضللًا. عمومًا، الشهادات الموقعة ذاتيًّا غير موصى بها حتى ولو كانت ستُستخدم في شبكة موثوقة (في إطار شبكة مؤسسية مثلًا خاضعة للرقابة). هناك توصيتان عليك مراعاتهما إن كنت في شبكة موثوق بها: الأولى هي استخدام البروتوكول http، لأن الشبكة نفسها موثوق بها، والثانية هي الحصول على شهادة موقعة من مرجع موثوق CA (وليس موقعة ذاتيًا). فإما أنّ الشبكة موثوقة، أو أنها ليست كذلك.

المبادئ الموضحة هنا ليست مقصورة على كوردوفا، بل تنطبق على جميع الاتصالات بين العميل والخادم.

عند تشغيل كوردوفا على أندرويد، فإنَّ استخدام android:debuggable="true"‎ في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة (certificate chain validation) على الشهادات الموقعة ذاتيَّا. لذلك، يمكنك استخدام الشهادات الموقعة ذاتيًا في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. يفترض استخدامه حصرًا أثناء مرحلة التطوير.

نصائح عامة

لا تستخدم إصدار أندرويد Gingerbread

قم بتعيين مستوى min-target-sdk عند رقم أعلى من 10.فالإصدار API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، لذلك لا يوصي به فريق كوردوفا.
لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو أحد منصات الهاتف الأكثر عرضة للاستهداف.
لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread و ما دونه. هذا يعني أنَّ المهاجم يمكنه تحميل شيفرة خبيثة في الإطار iframe الذكي، والتي ستكون قادرة على الوصول إلى جميع واجهات كوردوفا البرمجية، ما قد يمكن المخترق من سرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى.

استخدم InAppBrowser لأجل الوصلات الخارجية

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

تحقق من صحة جميع مدخلات المستخدم

تحقق من صحة أية مدخلات يقبلها تطبيقك دائمًا بما في ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لكون المهاجمين قادرين على العبث بأصول (ملفات) HTML و JS خاصتك (إما عن طريق عكس ترجمة [decompiling] التطبيق أو باستخدام أدوات التصحيح، مثل أداة chrome://inspect)، فيجب إجراء عملية التحقق هذه على الخادم أيضًا خاصةً قبل تسليم البيانات إلى خدمة خلفية (backend service).
هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (push notifications).

لا تخزن البيانات الحساسة

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

لا تستخدم الدالة eval()‎ إلا إذا كنت تعرف ما تفعله

لطالما أسيئ استخدام الدالةeval() ‎، فاستخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (injection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية.

لا تفترض أبدًا أن شيفرتك المصدرية آمنة

تُبنى تطبيقات كوردوفا من أصول (ملفات) HTML و JavaScript والتي تُحزم (packaged) في حاويات أصلية (native containers)، لذلك عليك ألا تفترض أنَّ شيفرتك آمنة أبدًا. فمن الممكن إجراء هندسة عكسية على تطبيقات كوردوفا.

انظر أيضا

مصادر

قسم الأمن في التوثيق الرسمي لكوردوفا.