الفرق بين المراجعتين ل"Cordova/security"
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude> تصنيف: Cordova تصنيف: security يتضمن الدليل التالي بعض أفضل...') |
|||
| سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude> | <noinclude>{{DISPLAYTITLE:الأمن في Cordova}}</noinclude> | ||
| − | [[تصنيف: Cordova]] | + | [[تصنيف: Cordova]] |
[[تصنيف: security]] | [[تصنيف: security]] | ||
| − | يتضمن الدليل التالي بعض أفضل | + | يتضمن الدليل التالي بعض أفضل الممارسات الأمنية التي يجب مراعاتها عند تطوير تطبيقات Cordova. يرجى الانتباه إلى أن الأمن موضوع معقد للغاية، وأنّ هذا الدليل ليس شاملاً. |
| − | + | تم تصميم هذا الدليل ليُطبّق على جميع منصات Cordova، الممارسات الخاصة بمنصات معينة ستتم الإشارة إليها في موضعها. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == اللائحة البيضاء == | + | == اللائحة البيضاء (Whitelist) == |
* | * | ||
| − | + | لا تعمل [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> أو إضافات الطرف الثالث الأخرى. | |
| − | |||
| − | + | == الإطارات الذكية وآلية تعريف الاستدعاء (Iframes and Callback Id Mechanism) == | |
| − | + | إذا تم عرض المحتوى في إطار ذكي انطلاقا من نطاق موجود في اللائحة البيضاء (whiteliste)، فسيكون لذلك النطاق حق الوصول إلى جسر Cordova الأولي (native Cordova bridge). وهذا يعني أنه في حال أضفت شبكة إعلانية تابعة لطرف ثالث إلى اللائحة البيضاء، وعرَضت تلك الإعلانات داخل إطار ذكي، فمن المحتمل أن يتمكن أحد الإعلانات الخبيثة من الخروج من الإطار الذكي ويفعل أشياء ضارة. لهذا السبب، يجب ألا تستخدم الإطارات الذكية عمومًا، إلا إن كنت تتحكم في الخادم الذي يستضيف محتوى الإطار الذكي. | |
| − | + | لاحظ أيضًا أن هناك إضافات متوفرة لدعم الشبكات الإعلانية. ولاحظ أيضًا أن هذا الأمر غير صحيح في منصة iOS، والتي تعترض كل شيء، بما في ذلك الاتصالات التي تجريها الإطارات الذكية. | |
| − | == تثبيت الشهادة == | + | == تثبيت الشهادة (Certificate Pinning) == |
| − | لا تدعم 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)، فمن المستحسن أن يكون لدى الخادم شهادة مٌوقّعة بشكل صحيح من قِبل مرجع موثوق (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 على أندرويد، فإن استخدام <code>android:debuggable="true"</code> في بيان التطبيق (application manifest) سيسمح بأخطاء SSL، مثل أخطاء التحقق من سلسلة الشهادة (certificate chain validation) على الشهادات الموقعة ذاتيا. لذلك يمكنك استخدام الشهادات الموقعة ذاتياً في إطار هذه الإعدادات، لكن لا ينبغي استخدام هذه الإعدادات عندما يكون التطبيق في مرحلة الإنتاج. فمن المفترض استخدامه حصرًا أثناء مرحلة التطوير. | ||
== نصائح عامة == | == نصائح عامة == | ||
=== لا تستخدم الإصدار Android Gingerbread=== | === لا تستخدم الإصدار Android Gingerbread=== | ||
| − | * قم بتعيين مستوى min-target-sdk غند | + | * قم بتعيين مستوى <code>min-target-sdk</code> غند رقم أعلى من 10.فالإصدار API 10 ينتمي إلى الإصدار Gingerbread، والذي لم يعد مدعومًا من قِبل Google أو مصنعي الأجهزة، لذلك لا يوصي به فريق Cordova. |
| − | * لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو | + | * لقد تبيّن أن الإصدار Gingerbread غير آمن، فهو [http://bgr.com/2012/11/06/android-security-gingerbread-malware/ أحد منصات الهاتف الأكثر عرضة للاستهداف]. |
| − | * لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread | + | * لا تعمل اللائحة البيضاء على أندرويد في الإصدار Gingerbread و ما دونه. هذا يعني أن المهاجم يمكنه تحميل شيفرة خبيثة في الإطار الذكي (iframe)، والذي سيكون قادرًا على الوصول إلى جميع واجهات Cordova البرمجية، ما قد يمكنه من سرقة البيانات الشخصية، وإرسال رسائل نصية إلى الأرقام الممتازة (premium-rate numbers) والقيام بأعمال خبيثة أخرى. |
| − | === استخدم InAppBrowser | + | === استخدم InAppBrowser لأجل الوصلات الخارجية === |
| − | * استخدم InAppBrowser عند فتح روابط لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن InAppBrowser ستستخدم ميزات الأمان الأصلية للمتصفح، ولن | + | * استخدم InAppBrowser عند فتح روابط موجهة لمواقع خارجية. يعد هذا الخيار أكثر أمانًا من إدراج اسم نطاق معين في اللائحة البيضاء وتضمين المحتوى في تطبيقك مباشرةً، لأن InAppBrowser ستستخدم ميزات الأمان الأصلية للمتصفح، ولن تمنح الموقع إمكانية الوصول إلى بيئة Cordova. حتى لو كنت تثق بموقع الطرف الثالث وقمت بتضمينه مباشرة في تطبيقك، فيمكن لذلك الموقع أن يرتبط بمحتوى من موقع ضار. |
=== تحقق من صحة جميع مدخلات المستخدم === | === تحقق من صحة جميع مدخلات المستخدم === | ||
| − | * تحقق من صحة أي مدخلات يقبلها تطبيقك دائمًا. | + | * تحقق من صحة أي مدخلات يقبلها تطبيقك دائمًا. بما في ذلك أسماء المستخدمين، وكلمات المرور، والتواريخ والوسائط المُحمّلة، وما إلى ذلك. نظرًا لكون المهاجمين قادرين على العبث بأصول (ملفات) [[HTML]] و [[JavaScript|JS]] خاصتك (إما عن طريق عكس ترجمة (decompiling) التطبيق أو باستخدام أدوات تصحيح الأخطاء، مثل أداة chrome://inspect)، يجب إجراء عملية التحقق هذه على الخادم أيضًا، خاصة قبل تسليم البيانات إلى خدمة خلفية (backend service). |
| − | * هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة ( | + | * هناك مصادر أخرى يجب التحقق من صحة البيانات الموجودة فيها، مثل: وثائق المستخدم، وجهات الاتصال، والإشعارات المدفوعة (push notifications). |
=== لا تخزن البيانات الحساسة === | === لا تخزن البيانات الحساسة === | ||
| − | * إذا تم تخزين أسماء المستخدمين وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن | + | * إذا تم تخزين أسماء المستخدمين وكلمات المرور، ومعلومات الموقع الجغرافي، والبيانات الحساسة الأخرى مؤقتًا، فمن الممكن أن تُسرق لاحقًا من قبل مستخدم أو تطبيق غير مصرح به. |
| − | === لا تستخدم eval() إلا إذا كنت تعرف ما تفعله === | + | === لا تستخدم الدالة <code>eval()</code> إلا إذا كنت تعرف ما تفعله === |
| − | * لطالما أسيئ استخدام دالة الجافاسكريبت eval() . | + | * لطالما أسيئ استخدام دالة الجافاسكريبت <code>[[JavaScript/eval|eval()]]</code> . وإنّ استخدامها بشكل غير صحيح قد يفتح ثغرات في شيفرتك البرمجية ويجعلها عرضة لهجمات الحقن (injection attacks)، إضافة إلى تصعيب تصحيح الأخطاء، وإبطاء تنفيذ الشيفرة البرمجية. |
=== لا تفترض أبدًا أن شيفرتك المصدرية آمنة === | === لا تفترض أبدًا أن شيفرتك المصدرية آمنة === | ||
| − | * | + | * تُبنى تطبيقات Cordova من أصول (ملفات) [[HTML]] و [[JavaScript]]، والتي تُحزم (packaged) في حاويات أصلية (native containers)، لذلك عليك ألا تعتبر شيفرتك آمنة أبدًا. فمن الممكن إجراء هندسة عكسية على تطبيقات Cordova. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==مصادر== | ==مصادر== | ||
*[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.