الفرق بين المراجعتين ل"Cordova/security"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude> تصنيف: Cordova تصنيف: security يتضمن الدليل التالي بعض أفضل...')
 
سطر 1: سطر 1:
 
<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude>
 
<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude>
[[تصنيف: Cordova]]
+
[[تصنيف: Cordova]]
 
[[تصنيف: security]]
 
[[تصنيف: security]]
يتضمن الدليل التالي بعض أفضل ممارسات الأمان التي يجب مراعاتها عند تطوير تطبيقات Cordova. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملاً. إذا كنت تعتقد أنه يمكنك المساهمة في هذا الدليل، فلا تتردد في تقديم مشكلة في تعقب الأخطاء في كوردوفا تحت [https://issues.apache.org/jira/browse/CB/component/12316407  "Documentation"].  تم تصميم هذا الدليل ليكون قابلاً للتطبيق على جميع منصات Cordova، ولكن سيتم الإشارة إلى الممارسات الخاصة بمنصات معينة.  
+
يتضمن الدليل التالي بعض أفضل الممارسات الأمنية التي يجب مراعاتها عند تطوير تطبيقات Cordova. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملاً.
  
== يناقش هذا الدليل المواضيع التالية: ==
+
تم تصميم هذا الدليل ليُطبّق على جميع منصات Cordova، الممارسات الخاصة بمنصات معينة ستتم الإشارة إليها في موضعها.
* اللوائح البيضاء (Whitelist )
 
* الإطارات الذكية (Iframes) وآلية تعريف الاستدعاء (Callback Id Mechanism)
 
* تثبيت الشهادة (Certificate Pinning)
 
* شهادات موقعة ذاتيا (Self-signed Certificates)
 
* تخزين مشفر (Encrypted storage)
 
*نصائح عامة
 
* مقالات ومصادر
 
  
== اللائحة البيضاء ==  
+
== اللائحة البيضاء (Whitelist) ==
 
*
 
*
  
قراءة وفهم [../whitelist/index.html Whitelist Guide]  
+
لا تعمل [https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html اللوائح البيضاء] على الواجهة البرمجية لأندرويد 10 (Android API 10) وما دونها، وكذلك ويندوز 8 للإطارات الذكية (iframe) ولكائنات <code>XMLHttpRequest</code>. هذا يعني أن المهاجم يمكنه تحميل نطاق (domain) ما في الإطار الذكي (iframe)، وستكون النصوص البرمجية الموجودة في الصفحة المُحمّلة داخل ذلك الإطار قادرة على الوصول مباشرةً إلى كائنات [[JavaScript]] في Cordova وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بعين الاعتبار عند إنشاء تطبيقات لهذه المنصات. وهذا يعني التأكد من أن واجهات أندرويد البرمجية التي تستهدفها من الإصدار العاشر فما فوق، وأن تتجنب قدر الإمكان استخدام الإطارات الذكية لتحميل المحتويات الخارجية - استخدم الإضافة <code>inAppBrowser</code> أو إضافات الطرف الثالث الأخرى.
*
 
  
لا تعمل اللوائح البيضاء للنطاقات على الواجهة البرمجية لأندرويد 10 وما دونه، و WP8 للإطارات الذكية (iframe) والكائن XMLHttpRequest. هذا يعني أن المهاجم يمكنه تحميل أي نطاق في إطار ذكي وأي نص برمجي في تلك الصفحة داخل ذلك الإطار يمكنه الوصول مباشرةً إلى كائنات JavaScript في Cordova وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بعين الاعتبار عند إنشاء تطبيقات لهذه المنصات. وهذا يعني التأكد من استهدافك لواجهة برمجة لأندرويد من الإصدار العاشر فما فوق، وأن تتجنب قد الإمكان استخدام الإطارات الذكية لتحميل المحتويات الخارجية - استخدم الإضافة inAppBrowser أو إضافات الطرف الثالث الأخرى.
+
== الإطارات الذكية وآلية تعريف الاستدعاء (Iframes and Callback Id Mechanism) ==
  
== الإطارات الذكية وآلية تعريف الاستدعاء Iframes and Callback Id Mechanism ==
+
إذا تم عرض المحتوى في إطار ذكي انطلاقا من نطاق موجود في اللائحة البيضاء (whiteliste)، فسيكون لذلك النطاق حق الوصول إلى جسر Cordova الأولي (native Cordova bridge). وهذا يعني أنه في حال أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرَضت تلك الإعلانات داخل إطار ذكي، فمن المحتمل أن يتمكن أحد الإعلانات الخبيثة من الخروج من الإطار الذكي ويفعل أشياء ضارة. لهذا السبب، يجب ألا تستخدم الإطارات الذكية عمومًا، إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي. 
  
إذا تم عرض المحتوى في إطار ذكي من نطاق من اللائحة البيضاء (whiteliste)، فسيكون لذلك النطاق حق الوصول إلى جسر Cordova الأولي (native Cordova bridge). وهذا يعني أنه إذا أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرضت تلك الإعلانات داخل إطار ذكي، فمن المحتمل أن يستطيع أحد الإعلانات الخبيثة الخروج من الإطار الذكي ويفعل أشياء ضارة. ولهذا السبب، يجب ألا تستخدم عمومًا الإطارات الذكية إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي.  لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. لاحظ أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات الذكية.  
+
لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. ولاحظ أيضًا أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات الذكية.  
  
== تثبيت الشهادة ==  
+
== تثبيت الشهادة (Certificate Pinning) ==  
  
لا تدعم Cordova تثبيت الشهادة بشكل فعلي. العائق الرئيسي أمام هذا هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات SSL لإجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندروبد في Java باستخدام JSSE، فإن طريقة المعرض webview على أندرويد مكتوب بلغة C++‎، ويتم التعامل مع اتصالات الخادم من خلال webview، لذلك لا يمكن استخدام Java و JSSE هناك.) نظرًا لأن Cordova تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإن عدم وجود إمكانية في منصة رئيسية هو ثغرة في هذا التناسق.  
+
لا تدعم Cordova تثبيت الشهادة بشكل فعلي. والعائق الرئيسي أمام ذلك هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات بروتوكول طبقة المقابس الآمنة (SSL) لأجل إجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندروبد في Java باستخدام JSSE، فإنّ المعرض webview على أندرويد مكتوب بلغة C++‎، ويتم التعامل مع اتصالات الخادم من طرف webview، لذلك لا يمكن استخدام Java و JSSE هناك.). نظرًا لأن Cordova تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإن عدم وجود إمكانية مهمة كهذه في منصة رئيسية هو ثغرة في هذا التناسق.  
  
هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (fingerprint) هو القيمة المتوقعة عند بدء تشغيل التطبيق، أو في أوقات مختلفة أخرى أثناء عمر تطبيقك. هناك عدة إضافات متاحة يمكنها القيام بذلك. لكن تذكر أن هذا لا يكافئ تثبيت الشهادة الحقيقي، الذي يتحقق تلقائيًا من القيمة المتوقعة عند كل عملية اتصال بالخادم.  
+
هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (fingerprint) هو القيمة المتوقعة عند بدء تشغيل التطبيق أو في أوقات أخرى أثناء عمر تطبيقك. كما أنّ هناك عدة إضافات متاحة يمكنها القيام بذلك. لكن تذكر أنّ هذا لا يكافئ تثبيت الشهادة الحقيقي، والذي يتحقق تلقائيًا من القيمة المتوقعة عند كل عملية اتصال بالخادم.  
  
هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (يعني غياب طلبيات XHR / AJAX التقليدية، وما إلى ذلك).  
+
هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (ما يعني غياب طلبيات XHR/AJAX التقليدية، وما إلى ذلك).  
  
 
== الشهادات الموقعة ذاتيا (Self-signed Certificates) ==  
 
== الشهادات الموقعة ذاتيا (Self-signed Certificates) ==  
  
لا ينصح باستخدام الشهادات الموقعة ذاتيا على خادمك. إن أردت استخدام SSL، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة بشكل صحيح من قِبل مرجع موثوق CA (certificate authority). عدم القدرة على القيام بالتثبيت الحقيقي للشهادة يجعل هذا مهمًا.  
+
لا ينصح باستخدام الشهادات الموقعة ذاتيا على خادمك. إن أردت استخدام بروتوكول طبقة المقابس الآمنة (SSL)، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة بشكل صحيح من قِبل مرجع موثوق (certificate authority). فعدم القدرة على القيام بالتثبيت الحقيقي للشهادة يجعل هذا ضروريًا.  
  
والسبب هو أن قبول الشهادات الموقعة ذاتيًا يتجاوز سلسلة عمليات التحقق من صحة الشهادة، ما قد يؤدي إلى اعتبار أي شهادة خادم صالحة من قبل الجهاز. هذا يجعل الاتصال عرضة لهجمات الوسطاء الخفيين (man-in-the-middle attacks). لم يعد من اليسير على المخترقين اعتراض وقراءة جميع الاتصالات بين الجهاز والخادم فحسب، بل صاروا أيضًا قادرين تعديل والعبث بتلك الاتصالات. لن يعلم الجهاز أبداً يحدوث هذا لأنه لا يتحقق من أن شهادة الخادم موقعة من قبل مرجع موثوق به (trusted CA). لا يوجد لدى الجهاز أي طريقة للتثبت من أنه يتعامل مع الخادم الذي يتوقعه. نظرًا لسهولة القيام بهجوم الوسيط الخفي (man-in-the-middle)، فإن قبول شهادات موقعة ذاتيًا أفضل بقليل وحسب من إجراء البروتوكول http بدلاً من https على شبكة غير موثوق بها. صحيح أن المعلومات ستكون مشفرة، ولكن يمكن للوسيط الخفي (man-in-the-middle) تحديد مفتاح تشفيرها، وإذا سيكون قادرًا على الوصول إلى كل شيء، لذا فإن التشفير غير ذي جدوى إلا اتُجاه المراقبين السلبيين (passive observers). يثق المستخدمون بأن بروتوكول طبقة المقابس الآمنة (SSL) آمنة، والمفارقة أن هذا من شأنه أن يجعلها غير آمنة، وبالتالي يصبح استخدام طبقة المقابس الآمنة مضللاً. إن كانت ستستخدم في شبكة موثوقة (مثلا في إطار شبكة مؤسسية خاضعة للرقابة)، فلا تزال الشهادات الموقعة ذاتيا غير موصى بها. هناك توصيتان عليك مراعاتهما إن كنت في شبكة موثوق بها، الأولى هي استخدام البروتوكول http، لأن الشبكة نفسها موثوق بها، والثانية هي الحصول على شهادة موقعة من مرجع موثوق CA (وليس موقعة ذاتيًا). إما أن الشبكة موثوقة، أو أنها ليست كذلك.
+
السبب هو أن قبول الشهادات الموقعة ذاتيًا يتجاوز عملية التحقق من سلسلة الشهادة (certificate chain validation)، ما قد يؤدي إلى اعتبار أي شهادة خادم صالحة من قبل الجهاز. هذا يجعل الاتصال عرضة لهجمات الوسطاء الخفيين (man-in-the-middle attacks).
  
المبادئ الموضحة هنا ليست مقصورة على Cordova، بل هي تنطبق على جميع الاتصالات بين العميل والخادم.  
+
لم يعد من اليسير على المخترقين اعتراض وقراءة جميع الاتصالات بين الجهاز والخادم فحسب، بل صاروا أيضًا قادرين على تعديل تلك الاتصالات والعبث بها. ولن يعلم الجهاز أبداً يحدوث هذا لأنه لا يتحقق من أنّ شهادة الخادم موقعة من قبل مرجع موثوق (trusted CA). لا يوجد لدى الجهاز أي طريقة للتثبت من أنه يتعامل مع الخادم الذي يتوقعه.
  
عند تشغيل Cordova على أندرويد، فإن استخدام <code>android:debuggable="true"</code> في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة على الشهادات الموقعة ذاتيا. لذلك يمكنك استخدام الشهادات الموقعة ذاتياً في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. فمن المفترض استخدامه حصرًا أثناء مرحلة التطوير.  
+
نظرًا لسهولة القيام بهجوم الوسيط الخفي (man-in-the-middle)، فإن أفضلية قبول شهادات موقعة ذاتيًا محدودة مقارنة بإجراء البروتوكول http بدلاً من https على شبكة غير موثوق بها. صحيح أن المعلومات ستكون مشفرة، ولكن يمكن للوسيط الخفي (man-in-the-middle) تحديد مفتاح تشفيرها، وإذن سيكون قادرًا على الوصول إلى كل شيء، لذا فإن التشفير غير ذي جدوى إلا اتُجاه المراقبين السلبيين (passive observers).
  
== التخزين المشفر ==
+
يثق المستخدمون بأن بروتوكول طبقة المقابس الآمنة (SSL) آمن، هذه الثقة من شأنها أن تجعله غير آمن، وبالتالي يصبح استخدام  SSL مضللاً. عمومًا،  الشهادات الموقعة ذاتيا غير موصى بها حتى ولو كانت ستُستخدم في شبكة موثوقة (مثلا في إطار شبكة مؤسسية خاضعة للرقابة). هناك توصيتان عليك مراعاتهما إن كنت في شبكة موثوق بها، الأولى هي استخدام البروتوكول http، لأن الشبكة نفسها موثوق بها، والثانية هي الحصول على شهادة موقعة من مرجع موثوق CA (وليس موقعة ذاتيًا). فإما أنّ الشبكة موثوقة، أو أنها ليست كذلك.
  
(يحدد لاحقا)  
+
المبادئ الموضحة هنا ليست مقصورة على Cordova، بل تنطبق على جميع الاتصالات بين العميل والخادم.
 +
 
 +
عند تشغيل Cordova على أندرويد، فإن استخدام <code>android:debuggable="true"‎</code> في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة (certificate chain validation) على الشهادات الموقعة ذاتيا. لذلك يمكنك استخدام الشهادات الموقعة ذاتياً في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. فمن المفترض استخدامه حصرًا أثناء مرحلة التطوير.
  
 
== نصائح عامة ==  
 
== نصائح عامة ==  
 
=== لا تستخدم الإصدار Android Gingerbread===  
 
=== لا تستخدم الإصدار Android Gingerbread===  
* قم بتعيين مستوى min-target-sdk غند مستوى أعلى من 10. API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، ولذلك لا يوصي به فريق Cordova.  
+
* قم بتعيين مستوى <code>min-target-sdk</code> غند رقم أعلى من 10.فالإصدار API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، لذلك لا يوصي به فريق Cordova.  
* لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو أحد منصات الهاتف الأكثر عرضة للاستهداف [http://bgr.com/2012/11/06/android-security-gingerbread-malware/ http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/].  
+
* لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو [http://bgr.com/2012/11/06/android-security-gingerbread-malware/ أحد منصات الهاتف الأكثر عرضة للاستهداف].  
* لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread أو ما دونه. هذا يعني أن المهاجم يمكنه تحميل شفرة خبيثة في الإطار الذكي (iframe) الذي سيكون قادرًا على الوصول إلى جميع واجهات Cordova البرمجية، ويمكنه استخدام ذلك لسرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام ذات الأسعار الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى.  
+
* لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread و ما دونه. هذا يعني أن المهاجم يمكنه تحميل شيفرة خبيثة في الإطار الذكي (iframe)، والذي سيكون قادرًا على الوصول إلى جميع واجهات Cordova البرمجية، ما قد يمكنه من سرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى.  
=== استخدم InAppBrowser للوصلات الخارجية ===  
+
=== استخدم InAppBrowser لأجل الوصلات الخارجية ===  
* استخدم InAppBrowser عند فتح روابط لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن InAppBrowser ستستخدم ميزات الأمان الأصلية للمتصفح، ولن يمنح الموقع إمكانية الوصول إلى بيئة Cordova. حتى لو كنت تثق بموقع الطرف الثالث وقمت بتضمينه مباشرة في تطبيقك، فيمكن لذلك الموقع أن يرتبط بمحتوى من موقع ضار.  
+
* استخدم InAppBrowser عند فتح روابط موجهة لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن InAppBrowser ستستخدم ميزات الأمان الأصلية للمتصفح، ولن تمنح الموقع إمكانية الوصول إلى بيئة Cordova. حتى لو كنت تثق بموقع الطرف الثالث وقمت بتضمينه مباشرة في تطبيقك، فيمكن لذلك الموقع أن يرتبط بمحتوى من موقع ضار.  
 
=== تحقق من صحة جميع مدخلات المستخدم ===  
 
=== تحقق من صحة جميع مدخلات المستخدم ===  
* تحقق من صحة أي مدخلات يقبلها تطبيقك دائمًا. يتضمن ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لأن المهاجمين يمكنهم العبث بأصول HTML و JS خاصتك (إما عن طريق عكس ترجمة (decompiling) التطبيق أو استخدام أدوات تصحيح الأخطاء مثل أداة chrome://inspect)، يجب إجراء عملية التحقق هذه على الخادم أيضًا، خاصة قبل تسليم البيانات إلى خدمة خلفية (backend service).  
+
* تحقق من صحة أي مدخلات يقبلها تطبيقك دائمًا. بما في ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لكون المهاجمين قادرين على العبث بأصول (ملفات) [[HTML]] و [[JavaScript|JS]] خاصتك (إما عن طريق عكس ترجمة (decompiling) التطبيق أو باستخدام أدوات تصحيح الأخطاء، مثل أداة chrome://inspect)، يجب إجراء عملية التحقق هذه على الخادم أيضًا، خاصة قبل تسليم البيانات إلى خدمة خلفية (backend service).  
* هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (backend service).  
+
* هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (push notifications).  
 
=== لا تخزن البيانات الحساسة ===  
 
=== لا تخزن البيانات الحساسة ===  
* إذا تم تخزين أسماء المستخدمين وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن المحتمل أن تُسترد لاحقًا من قبل مستخدم أو تطبيق غير مصرح به.  
+
* إذا تم تخزين أسماء المستخدمين وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن الممكن أن تُسرق لاحقًا من قبل مستخدم أو تطبيق غير مصرح به.  
=== لا تستخدم eval()‎ إلا إذا كنت تعرف ما تفعله ===  
+
=== لا تستخدم الدالة <code>eval()‎</code> إلا إذا كنت تعرف ما تفعله ===  
* لطالما أسيئ استخدام دالة الجافاسكريبت eval() ‎ . إن استخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (njection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية.  
+
* لطالما أسيئ استخدام دالة الجافاسكريبت <code>[[JavaScript/eval|eval()]]</code> ‎ . وإنّ استخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (injection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية.  
 
=== لا تفترض أبدًا أن شيفرتك المصدرية آمنة ===  
 
=== لا تفترض أبدًا أن شيفرتك المصدرية آمنة ===  
* يتم بناء تطبيقات Cordova من أصول (ملفات) HTML وجافا سكريبت، والتي تُحزم في حاويات أصلية (native containers)، لذلك عليك ألا تعتبر شيفرتك آمنة أبدًا. من الممكن إجراء هندسة عكسية على تطبيقات Cordova.  
+
* تُبنى تطبيقات Cordova من أصول (ملفات) [[HTML]] و [[JavaScript]]، والتي تُحزم (packaged) في حاويات أصلية (native containers)، لذلك عليك ألا تعتبر شيفرتك آمنة أبدًا. فمن الممكن إجراء هندسة عكسية على تطبيقات Cordova.  
 
 
== انظر أيضًا ==
 
[https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet  HTML5 Security cheat sheet, detailing how to secure your HTML5 application]
 
[https://github.com/phonegap/phonegap/wiki/Platform-Security  Phonegap's article on device security, such as using encrypted data]
 
[http://www.cis.syr.edu/%7Ewedu/Research/paper/webview_acsac2011.pdf  Whitepaper about well known security flaws in Webview based hybrid applications]
 
 
==مصادر==
 
==مصادر==
 
*[https://cordova.apache.org/docs/en/latest/guide/appdev/security/index.html قسم الأمن في التوثيق الرسمي لكوردوفا.]
 
*[https://cordova.apache.org/docs/en/latest/guide/appdev/security/index.html قسم الأمن في التوثيق الرسمي لكوردوفا.]

مراجعة 22:10، 19 نوفمبر 2018

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

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

اللائحة البيضاء (Whitelist)

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

الإطارات الذكية وآلية تعريف الاستدعاء (Iframes and Callback Id Mechanism)

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

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

تثبيت الشهادة (Certificate Pinning)

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

هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (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 (وليس موقعة ذاتيًا). فإما أنّ الشبكة موثوقة، أو أنها ليست كذلك.

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

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

نصائح عامة

لا تستخدم الإصدار Android Gingerbread

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

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

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

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

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

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

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

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

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

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

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

مصادر