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

المراجعة الحالية بتاريخ 09:47، 1 ديسمبر 2020

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

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

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

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

انظر أيضًا

مصادر

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

@@ سطر 1: / سطر 1: @@
-<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude>
+<noinclude>{{DISPLAYTITLE:إدارة الأمن في كوردوفا}}</noinclude>
 [[تصنيف: Cordova]]
-[[تصنيف: security]]
+يتضمن الدليل التالي بعض أفضل الممارسات الأمنية التي يجب مراعاتها عند تطوير تطبيقات كوردوفا. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملًا.
-يتضمن الدليل التالي بعض أفضل ممارسات الأمان التي يجب مراعاتها عند تطوير تطبيقات Cordova. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملاً. إذا كنت تعتقد أنه يمكنك المساهمة في هذا الدليل، فلا تتردد في تقديم مشكلة في تعقب الأخطاء في كوردوفا تحت [https://issues.apache.org/jira/browse/CB/component/12316407  "Documentation"].  تم تصميم هذا الدليل ليكون قابلاً للتطبيق على جميع منصات Cordova، ولكن سيتم الإشارة إلى الممارسات الخاصة بمنصات معينة.
-== يناقش هذا الدليل المواضيع التالية: ==
+تم تصميم هذا الدليل ليُطبّق على جميع منصات كوردوفا؛ الممارسات الخاصة بمنصات معينة سيُشار إليها في موضعها.
-* اللوائح البيضاء (Whitelist )
+==اللائحة البيضاء==
-* الإطارات الذكية (Iframes) وآلية تعريف الاستدعاء (Callback Id Mechanism)
+لا تعمل [[Cordova/whitelist|اللوائح البيضاء]] (Whitelist) على الواجهة البرمجية لأندرويد 10 (Android API 10) وما دونها، وكذلك ويندوز 8 للإطارات iframe ولكائنات <code>XMLHttpRequest</code>. هذا يعني أن المهاجم يمكنه تحميل نطاق (domain) ما في الإطار iframe، وستكون النصوص البرمجية الموجودة في الصفحة المُحمّلة داخل ذلك الإطار قادرة على الوصول مباشرةً إلى كائنات [[JavaScript]] في كوردوفا وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بالحسبان عند إنشاء تطبيقات لهذه المنصات. هذا يعني التأكد من أن واجهات أندرويد البرمجية التي تستهدفها من الإصدار العاشر فما فوق، وأن تتجنب قدر الإمكان استخدام الإطارات iframe لتحميل المحتويات الخارجية؛ استخدم الإضافة <code>inAppBrowser</code> أو إضافات أخرى من طرف ثالث.
-* تثبيت الشهادة (Certificate Pinning)
+==الإطارات iframe الذكية وآلية تعريف الاستدعاء==
-* شهادات موقعة ذاتيا (Self-signed Certificates)
+إذا عُرض المحتوى في إطار iframe ذكي انطلاقًا من نطاق موجود في [[Cordova/whitelist|اللائحة البيضاء]]، فسيكون لذلك النطاق حق الوصول إلى جسر كوردوفا الأولي (native Cordova bridge). وهذا يعني أنه في حال أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرَضت تلك الإعلانات داخل الإطار iframe الذكي، فمن المحتمل أن يتمكن أحد الإعلانات الخبيثة من الخروج من الإطار الذكي وفعل أشياء ضارة. لهذا السبب، يجب ألا تستخدم الإطارات iframe الذكية عمومًا، إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي.
-* تخزين مشفر (Encrypted storage)
-*نصائح عامة
-* مقالات ومصادر
-== اللائحة البيضاء ==
+لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. ولاحظ أيضًا أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات iframe الذكية.
-*
+==تثبيت الشهادة==
+لا تدعم كوردوفا تثبيت الشهادة (Certificate Pinning) فعليا. والعائق الرئيسي أمام ذلك هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات بروتوكول طبقة المقابس الآمنة (SSL) لأجل إجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندرويد في Java باستخدام JSSE، فإنّ المعرض webview على أندرويد مكتوب بلغة C++‎، ويتم التعامل مع اتصالات الخادم من طرف webview، لذلك لا يمكن استخدام Java  و JSSE هناك.) نظرًا لأن كوردوفا تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإنَّ عدم وجود إمكانية مهمة كهذه في منصة رئيسية هو ثغرة في هذا التناسق.
-قراءة وفهم [../whitelist/index.html  Whitelist Guide]
+هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (fingerprint) هو القيمة المتوقعة عند بدء تشغيل التطبيق أو في أوقات أخرى أثناء عمر تطبيقك. كما أنّ هناك عدة إضافات متاحة يمكنها القيام بذلك. على أي حال، تذكر أنّ هذا لا يكافئ تثبيت الشهادة الحقيقي الذي يتحقق تلقائيًا من القيمة المتوقعة عند كل عملية اتصال بالخادم.
-*
-لا تعمل اللوائح البيضاء للنطاقات على الواجهة البرمجية لأندرويد 10 وما دونه، و WP8 للإطارات الذكية (iframe) والكائن XMLHttpRequest. هذا يعني أن المهاجم يمكنه تحميل أي نطاق في إطار ذكي وأي نص برمجي في تلك الصفحة داخل ذلك الإطار يمكنه الوصول مباشرةً إلى كائنات JavaScript في Cordova وكائنات Java الأصلية المقابلة. يجب أخذ ذلك بعين الاعتبار عند إنشاء تطبيقات لهذه المنصات. وهذا يعني التأكد من استهدافك لواجهة برمجة لأندرويد من الإصدار العاشر فما فوق، وأن تتجنب قد الإمكان استخدام الإطارات الذكية لتحميل المحتويات الخارجية - استخدم الإضافة inAppBrowser أو إضافات الطرف الثالث الأخرى.
+هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (ما يعني غياب طلبيات XHR/AJAX التقليدية وغيرها).
+==الشهادات الموقعة ذاتيا==
+لا ينصح باستخدام الشهادات الموقعة  (Self-signed Certificates) ذاتيًّا على خادمك. إن أردت استخدام بروتوكول طبقة المقابس الآمنة (SSL)، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة من قِبل مرجع موثوق (certificate authority). فعدم القدرة على القيام بالتثبيت الحقيقي للشهادة يجعل هذا ضروريًا.
-== الإطارات الذكية وآلية تعريف الاستدعاء Iframes and Callback Id Mechanism ==
+السبب هو أن قبول الشهادات الموقعة ذاتيًا يتجاوز عملية التحقق من سلسلة الشهادة (certificate chain validation) ما قد يؤدي إلى اعتبار أية شهادة خادم صالحة من قبل الجهاز. هذا يجعل الاتصال عرضة لهجمات الوسطاء الخفيين (man-in-the-middle attacks).
-إذا تم عرض المحتوى في إطار ذكي من نطاق من اللائحة البيضاء (whiteliste)، فسيكون لذلك النطاق حق الوصول إلى جسر Cordova الأولي (native Cordova bridge). وهذا يعني أنه إذا أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرضت تلك الإعلانات داخل إطار ذكي، فمن المحتمل أن يستطيع أحد الإعلانات الخبيثة الخروج من الإطار الذكي ويفعل أشياء ضارة. ولهذا السبب، يجب ألا تستخدم عمومًا الإطارات الذكية إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي.  لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. لاحظ أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات الذكية.
+لم يعد مُيسّرا للمخترقين اعتراض وقراءة جميع الاتصالات بين الجهاز والخادم فحسب، بل صاروا أيضًا قادرين على تعديل تلك الاتصالات والعبث بها. ولن يعلم الجهاز أبدًا بحدوث ذلك لأنه لا يتحقق من أنّ شهادة الخادم موقعة من قبل مرجع موثوق (trusted CA). لا يوجد لدى الجهاز أي طريقة للتثبت من أنه يتعامل مع الخادم الذي يتوقعه.
-== تثبيت الشهادة ==
+نظرًا لسهولة القيام بهجوم الوسيط الخفي (man-in-the-middle)، فإن أفضلية قبول شهادات موقعة ذاتيًا محدودة مقارنة بإجراء البروتوكول http بدلًا من https على شبكة غير موثوق بها. صحيح أن المعلومات ستكون مشفرة، ولكن يمكن للوسيط الخفي (man-in-the-middle) تحديد مفتاح تشفيرها، لذا سيكون قادرًا على الوصول إلى كل شيء؛ بناءً على ذلك، فإن التشفير غير ذي جدوى باستثناء اتجاه المراقبين السلبيين (passive observers).
-لا تدعم Cordova تثبيت الشهادة بشكل فعلي. العائق الرئيسي أمام هذا هو عدم وجود واجهات برمجية أصلية (native APIs) في أندرويد لاعتراض اتصالات SSL لإجراء فحص شهادة الخادم. (على الرغم من أنه من الممكن تنفيذ عملية تثبيت الشهادات على أندروبد في Java باستخدام JSSE، فإن طريقة المعرض webview على أندرويد مكتوب بلغة C++‎، ويتم التعامل مع اتصالات الخادم من خلال webview، لذلك لا يمكن استخدام Java و JSSE هناك.) نظرًا لأن Cordova تهدف إلى توفير واجهات برمجية متسقة تعمل عبر مختلف المنصات، فإن عدم وجود إمكانية في منصة رئيسية هو ثغرة في هذا التناسق.
+يثق المستخدمون بأن بروتوكول طبقة المقابس الآمنة (SSL) آمن، إذ هذه الثقة من شأنها أن تجعله غير آمن، وبالتالي يصبح استخدام  SSL مضللًا. عمومًا، الشهادات الموقعة ذاتيًّا غير موصى بها حتى ولو كانت ستُستخدم في شبكة موثوقة (في إطار شبكة مؤسسية مثلًا خاضعة للرقابة). هناك توصيتان عليك مراعاتهما إن كنت في شبكة موثوق بها: الأولى هي استخدام البروتوكول http، لأن الشبكة نفسها موثوق بها، والثانية هي الحصول على شهادة موقعة من مرجع موثوق CA (وليس موقعة ذاتيًا). فإما أنّ الشبكة موثوقة، أو أنها ليست كذلك.
-هناك عدة طرق لمقاربة عملية تثبيت الشهادة، مثل التحقق من أن المفتاح العمومي للخادم (fingerprint) هو القيمة المتوقعة عند بدء تشغيل التطبيق، أو في أوقات مختلفة أخرى أثناء عمر تطبيقك. هناك عدة إضافات متاحة يمكنها القيام بذلك. لكن تذكر أن هذا لا يكافئ تثبيت الشهادة الحقيقي، الذي يتحقق تلقائيًا من القيمة المتوقعة عند كل عملية اتصال بالخادم.
+المبادئ الموضحة هنا ليست مقصورة على كوردوفا، بل تنطبق على جميع الاتصالات بين العميل والخادم.
-هناك أيضًا إضافات يمكنها إجراء تثبيت حقيقي للشهادات لبعض المنصات، على افتراض أن تطبيقك قادر على تنفيذ جميع طلبيات الشبكة (network requests) باستخدام الإضافة (يعني غياب طلبيات XHR / AJAX التقليدية، وما إلى ذلك).
+عند تشغيل كوردوفا على أندرويد، فإنَّ استخدام <code>android:debuggable="true"‎</code> في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة (certificate chain validation) على الشهادات الموقعة ذاتيَّا. لذلك، يمكنك استخدام الشهادات الموقعة ذاتيًا في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. يفترض استخدامه حصرًا أثناء مرحلة التطوير.
+==نصائح عامة==
+'''لا تستخدم إصدار أندرويد Gingerbread'''
+*عيِّن مستوى <code>min-target-sdk</code> عند رقم أعلى من 10.فالإصدار API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، لذلك لا يوصي به فريق كوردوفا.
+*لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو [http://bgr.com/2012/11/06/android-security-gingerbread-malware/ أحد منصات الهاتف الأكثر عرضة للاستهداف].
+*لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread و ما دونه. هذا يعني أنَّ المهاجم يمكنه تحميل شيفرة خبيثة في الإطار iframe الذكي، والتي ستكون قادرة على الوصول إلى جميع واجهات كوردوفا البرمجية، ما قد يمكن المخترق من سرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى.
+'''استخدم <code>InAppBrowser</code> لأجل الوصلات الخارجية'''
+*استخدم <code>InAppBrowser</code> عند فتح روابط موجهة لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن <code>InAppBrowser</code> ستستخدم ميزات الأمان الأصلية للمتصفح، ولن تمنح الموقع إمكانية الوصول إلى بيئة كوردوفا. حتى لو كنت تثق بموقع الطرف الثالث وقمت بتضمينه مباشرة في تطبيقك، فيمكن لذلك الموقع أن يرتبط بمحتوى من موقع ضار.
+'''تحقق من صحة جميع مدخلات المستخدم'''
+*تحقق من صحة أية مدخلات يقبلها تطبيقك دائمًا بما في ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لكون المهاجمين قادرين على العبث بأصول (ملفات) [[HTML]] و [[JavaScript|JS]] خاصتك (إما عن طريق عكس ترجمة [decompiling] التطبيق أو باستخدام أدوات التصحيح، مثل أداة chrome://inspect)، فيجب إجراء عملية التحقق هذه على الخادم أيضًا خاصةً قبل تسليم البيانات إلى خدمة خلفية (backend service).
+*هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (push notifications).
+'''لا تخزن البيانات الحساسة'''
+*إذا تم تخزين أسماء المستخدمين، وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن الممكن أن تُسرَق لاحقًا من قبل مستخدم أو تطبيق غير مصرح به.
+'''لا تستخدم الدالة <code>eval()‎</code> إلا إذا كنت تعرف ما تفعله'''
+*لطالما أسيئ استخدام الدالة<nowiki/>[[JavaScript/eval|<code>eval()</code>]] ‎، فاستخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (injection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية.
+'''لا تفترض أبدًا أن شيفرتك المصدرية آمنة'''
+*تُبنى تطبيقات كوردوفا من أصول (ملفات) [[HTML]] و [[JavaScript]] والتي تُحزم (packaged) في حاويات أصلية (native containers)، لذلك عليك ألا تفترض أنَّ شيفرتك آمنة أبدًا. فمن الممكن إجراء هندسة عكسية لتطبيقات كوردوفا.
-== الشهادات الموقعة ذاتيا (Self-signed Certificates) ==
+== انظر أيضًا ==
+* [[Cordova/whitelist|اللوائح البيضاء]].
+* [[Cordova/privacy|إدارة الخصوصية]].
-لا ينصح باستخدام الشهادات الموقعة ذاتيا على خادمك. إن أردت استخدام 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 على أندرويد، فإن استخدام <code>android:debuggable="true"</code> في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة على الشهادات الموقعة ذاتيا. لذلك يمكنك استخدام الشهادات الموقعة ذاتياً في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. فمن المفترض استخدامه حصرًا أثناء مرحلة التطوير.
-== التخزين المشفر ==
-(يحدد لاحقا)
-== نصائح عامة ==
-=== لا تستخدم الإصدار Android Gingerbread===
-* قم بتعيين مستوى min-target-sdk غند مستوى أعلى من 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 أو ما دونه. هذا يعني أن المهاجم يمكنه تحميل شفرة خبيثة في الإطار الذكي (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.
-== انظر أيضًا ==
-[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 قسم الأمن في التوثيق الرسمي لكوردوفا.]