قائمة التحقق من الأمان

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

تساعدك ميزات الأمان الأساسية التالية في إنشاء تطبيقات آمنة:

  • بيئة الاختبار المعزولة لتطبيقات Android، والتي تعزل بيانات تطبيقك وتنفيذ الرموز البرمجية عن التطبيقات الأخرى
  • إطار عمل للتطبيقات يتضمّن عمليات تنفيذ قوية لوظائف الأمان الشائعة، مثل التشفير والأذونات والتواصل الآمن بين العمليات (IPC).
  • تتوفّر تقنيات مثل توزيع مساحة العناوين بشكل عشوائي (ASLR) وعدم التنفيذ (NX) وProPolice وsafe_iop وOpenBSD dlmalloc وcalloc وLinux mmap_min_addr للحدّ من المخاطر المرتبطة بأخطاء إدارة الذاكرة الشائعة.
  • أذونات يمنحها المستخدم للحدّ من الوصول إلى ميزات النظام وبيانات المستخدم
  • أذونات يحدّدها التطبيق للتحكّم في بيانات التطبيق على أساس كل تطبيق على حدة.

من المهم أن تكون على دراية بأفضل ممارسات الأمان على Android الواردة في هذه الصفحة. يساعدك اتّباع هذه الممارسات كعادات عامة في الترميز على تجنُّب إدخال مشاكل أمان عن غير قصد تؤثر سلبًا في المستخدمين.

المصادقة

تُعد المصادقة شرطًا أساسيًا للعديد من عمليات الأمان الرئيسية. للتحكّم في إمكانية الوصول إلى مواد محمية، مثل بيانات المستخدمين ووظائف التطبيق والموارد الأخرى، عليك إضافة مصادقة إلى تطبيق Android.

يمكنك تحسين تجربة مصادقة المستخدم من خلال دمج تطبيقك مع Credential Manager. ‫Credential Manager هي مكتبة Android Jetpack توفّر دعمًا موحّدًا لواجهات برمجة التطبيقات لمعظم طرق المصادقة الرئيسية، بما في ذلك مفاتيح المرور وكلمات المرور وحلول تسجيل الدخول الموحّد، مثل تسجيل الدخول باستخدام حساب Google.

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

يمكن لإطار الملء التلقائي في Android تسهيل عملية الاشتراك وتسجيل الدخول، ما يقلّل من معدلات الخطأ وإزعاج المستخدمين. تتكامل ميزة "الملء التلقائي" مع تطبيقات إدارة كلمات المرور، ما يتيح للمستخدمين اختيار كلمات مرور معقّدة وعشوائية يمكن تخزينها واستردادها بسهولة وأمان.

ميزة "الحماية التلقائية من الأنشطة غير المسموح بها"

تساعدك Play Integrity API في التحقّق من أنّ التفاعلات وطلبات الخادم صادرة من البرنامج الثنائي الحقيقي لتطبيقك الذي يتم تشغيله على جهاز Android حقيقي. من خلال رصد عمليات التفاعل الخطيرة والاحتيالية المحتمَلة، مثل تلك التي تحدث من خلال إصدارات معدَّلة من التطبيق وبيئات غير موثوق بها، يمكن لخادم الخلفية في تطبيقك الاستجابة من خلال اتّخاذ الإجراءات المناسبة لمنع الهجمات والحدّ من إساءة الاستخدام.

تخزين البيانات

إنّ أكثر ما يثير القلق بشأن أمان التطبيقات على Android هو ما إذا كانت التطبيقات الأخرى يمكنها الوصول إلى البيانات التي تحفظها على الجهاز. هناك ثلاث طرق أساسية لحفظ البيانات على الجهاز:

  • وحدة التخزين الداخلية
  • وحدة تخزين خارجية
  • موفّرو المحتوى

توضّح الأقسام التالية مشاكل الأمان المرتبطة بكل طريقة.

وحدة التخزين الداخلية

بشكلٍ تلقائي، لا يمكن الوصول إلى الملفات التي تنشئها على وحدة التخزين الداخلية إلا من خلال تطبيقك، ويوفّر نظام التشغيل Android هذه الحماية، وهي كافية لمعظم التطبيقات.

تجنَّب استخدام الوضعَين المتوقّفَين نهائيًا MODE_WORLD_WRITEABLE وMODE_WORLD_READABLE لملفات IPC. ولا توفّر هذه الأنظمة إمكانية حصر الوصول إلى البيانات بتطبيقات معيّنة، كما أنّها لا توفّر أي تحكّم في تنسيق البيانات. إذا كنت تريد مشاركة بياناتك مع عمليات تطبيقات أخرى، ننصحك باستخدام موفّر محتوى بدلاً من ذلك، إذ يوفّر أذونات القراءة والكتابة للتطبيقات الأخرى ويمكنه منح الأذونات بشكل ديناميكي حسب كل حالة على حدة.

وحدة تخزين خارجية

يمكن قراءة الملفات التي تم إنشاؤها على وحدة التخزين الخارجية، مثل بطاقات SD، وكتابتها على مستوى العالم. بما أنّ المستخدم يمكنه إزالة وحدة التخزين الخارجية ويمكن لأي تطبيق تعديلها، لا تخزِّن سوى المعلومات غير الحسّاسة باستخدام وحدة التخزين الخارجية.

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

موفّرو المحتوى

توفّر جهات توفير المحتوى آلية تخزين منظَّمة يمكن حصرها في تطبيقك أو تصديرها للسماح للتطبيقات الأخرى بالوصول إليها. إذا لم تكن تنوي منح التطبيقات الأخرى إذن الوصول إلى ContentProvider، ضَع علامة android:exported=false في ملف بيان التطبيق. بخلاف ذلك، اضبط السمة android:exported على true للسماح للتطبيقات الأخرى بالوصول إلى البيانات المخزَّنة.

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

إذا كنت تستخدم موفّر محتوى لمشاركة البيانات بين تطبيقاتك فقط، ننصحك باستخدام مجموعة السمات android:protectionLevel التي تم ضبطها على الحماية signature. لا تتطلّب أذونات التوقيع تأكيدًا من المستخدم، لذا فهي توفّر تجربة أفضل للمستخدم وتتيح الوصول بشكل أكثر تحكّمًا إلى بيانات مقدّم المحتوى عندما تكون التطبيقات التي تصل إلى البيانات موقّعة باستخدام المفتاح نفسه.

يمكن لمقدّمي المحتوى أيضًا توفير إذن وصول أكثر دقة من خلال تعريف السمة android:grantUriPermissions واستخدام العلامتَين FLAG_GRANT_READ_URI_PERMISSION وFLAG_GRANT_WRITE_URI_PERMISSION في العنصر Intent الذي يفعّل المكوّن. يمكن حصر نطاق هذه الأذونات بشكل أكبر باستخدام العنصر <grant-uri-permission>.

عند الوصول إلى موفّر محتوى، استخدِم طرق طلب بحث تتضمّن معلَمات، مثل query وupdate وdelete() لتجنُّب إدخال رموز SQL محتملة من مصادر غير موثوق بها. يُرجى العِلم أنّ استخدام الطرق التي تتضمّن مَعلمات ليس كافيًا إذا تم إنشاء وسيطة selection من خلال ربط بيانات المستخدم قبل إرسالها إلى الطريقة.

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

الأذونات

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

طلبات الإذن

تقليل عدد الأذونات التي يطلبها تطبيقك يؤدي حصر الوصول إلى الأذونات الحسّاسة إلى الحد من خطر إساءة استخدام هذه الأذونات بدون قصد، ويحسّن من معدّل استخدام التطبيق، ويجعله أقل عرضة للهجمات. بشكل عام، إذا لم يكن الإذن مطلوبًا لكي يعمل تطبيقك، لا تطلبه. اطّلِع على الدليل الخاص بتقييم ما إذا كان تطبيقك يحتاج إلى الإعلان عن الأذونات.

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

بالإضافة إلى طلب الأذونات، يمكن لتطبيقك استخدام العنصر <permission> لحماية عمليات الاتصال بين العمليات (IPC) التي تتضمّن بيانات حساسة للأمان ويتم عرضها للتطبيقات الأخرى، مثل ContentProvider. بشكل عام، ننصح باستخدام عناصر تحكّم في الوصول غير الأذونات التي يؤكّدها المستخدمون، وذلك حيثما أمكن، لأنّ الأذونات قد تكون مربكة للمستخدمين. على سبيل المثال، ننصحك باستخدام مستوى حماية التوقيع في الأذونات الخاصة بالتواصل بين العمليات (IPC) بين التطبيقات التي يوفّرها مطوّر واحد.

عدم تسريب البيانات المحمية بالأذونات يحدث ذلك عندما يعرض تطبيقك بيانات عبر عملية الاتصال بين العمليات (IPC) لا تتوفّر إلا لأنّ تطبيقك لديه إذن بالوصول إلى هذه البيانات. قد لا يملك عملاء واجهة IPC الخاصة بتطبيقك إذن الوصول إلى البيانات نفسه. تتوفّر المزيد من التفاصيل حول معدّل تكرار هذه المشكلة وتأثيراتها المحتملة في ورقة البحث إعادة تفويض الأذونات: الهجمات والدفاعات المنشورة في USENIX.

تعريفات الأذونات

حدِّد أصغر مجموعة من الأذونات التي تستوفي متطلبات الأمان. إنّ إنشاء إذن جديد أمر غير شائع نسبيًا بالنسبة إلى معظم التطبيقات، لأنّ الأذونات المحدّدة من النظام تغطي العديد من الحالات. عند الاقتضاء، نفِّذ عمليات التحقّق من إذن الوصول باستخدام الأذونات الحالية.

إذا كنت بحاجة إلى إذن جديد، فكِّر في ما إذا كان بإمكانك إنجاز مهمتك باستخدام مستوى حماية التوقيع. تكون أذونات التوقيع شفافة للمستخدم، ولا تسمح بالوصول إلا للتطبيقات التي وقّعها المطوّر نفسه الذي وقّع التطبيق الذي يجري عملية التحقّق من الأذونات.

إذا كان إنشاء إذن جديد لا يزال مطلوبًا، يجب الإفصاح عنه في بيان التطبيق باستخدام العنصر <permission>. يمكن للتطبيقات التي تستخدم الإذن الجديد الرجوع إليه من خلال إضافة عنصر <uses-permission> في ملفات البيان. يمكنك أيضًا إضافة الأذونات بشكل ديناميكي باستخدام طريقة addPermission().

في حال إنشاء إذن بمستوى حماية خطير، هناك عدد من التعقيدات التي يجب مراعاتها:

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

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

الاتصال بالشبكات

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

ربط الأجهزة بشبكة IP

لا تختلف الشبكات على Android كثيرًا عن بيئات Linux الأخرى. والاعتبار الأساسي هو التأكّد من استخدام البروتوكولات المناسبة للبيانات الحسّاسة، مثل HttpsURLConnection لنقل بيانات الويب بشكل آمن. استخدِم بروتوكول HTTPS بدلاً من HTTP في أي مكان يتوفّر فيه بروتوكول HTTPS على الخادم، لأنّ الأجهزة الجوّالة تتصل بشكل متكرّر بشبكات غير آمنة، مثل شبكات Wi‑Fi العامة.

يمكن تنفيذ عملية التواصل المصادق عليها والمشفّرة على مستوى المقبس بسهولة باستخدام الفئة SSLSocket. نظرًا إلى معدّل تكرار اتصال أجهزة Android بشبكات لاسلكية غير آمنة باستخدام Wi-Fi، ننصح بشدة باستخدام شبكات آمنة لجميع التطبيقات التي تتواصل عبر الشبكة.

تستخدم بعض التطبيقات منافذ شبكة localhost للتعامل مع عمليات الاتصال بين العمليات (IPC) الحساسة. لا تستخدِم هذا الأسلوب، لأنّ هذه الواجهات يمكن أن تصل إليها تطبيقات أخرى على الجهاز. بدلاً من ذلك، استخدِم آلية IPC في Android حيث يمكن إجراء المصادقة، مثل Service. يكون الربط بعنوان IP غير محدّد INADDR_ANY أسوأ من استخدام عنوان IP الخاص بالشبكة المحلية، لأنّه يتيح لتطبيقك تلقّي طلبات من أي عنوان IP.

تأكَّد من عدم الوثوق بالبيانات التي يتم تنزيلها من HTTP أو بروتوكولات أخرى غير آمنة. ويشمل ذلك التحقّق من صحة البيانات المدخلة في WebView وأي ردود على طلبات صادرة عن HTTP.

شبكات الاتصالات الهاتفية

تم تصميم بروتوكول خدمة الرسائل القصيرة (SMS) في الأساس للتواصل بين المستخدمين، وهو غير مناسب للتطبيقات التي تريد نقل البيانات. بسبب القيود المفروضة على الرسائل القصيرة، ننصحك باستخدام خدمة المراسلة عبر السحابة الإلكترونية من Firebase (FCM) وشبكة IP لإرسال رسائل البيانات من خادم ويب إلى تطبيقك على جهاز المستخدم.

يُرجى العِلم أنّ الرسائل القصيرة SMS ليست مشفّرة ولا يتم تأكيد هويتك بشكل قوي على الشبكة أو الجهاز. على وجه الخصوص، يجب أن يتوقّع أي مستلِم لرسالة SMS أن يكون مستخدم ضار قد أرسل الرسالة إلى تطبيقك. لا تعتمد على بيانات الرسائل القصيرة غير المصادَق عليها لتنفيذ أوامر حساسة. يُرجى العِلم أيضًا بأنّ الرسائل القصيرة SMS قد تتعرّض للتزييف و/أو الاعتراض على الشبكة. على جهاز Android نفسه، يتم إرسال رسائل SMS كإشعارات بث، وبالتالي يمكن للتطبيقات الأخرى التي لديها إذن READ_SMS قراءتها أو تسجيلها.

التحقّق من صحة البيانات المُدخَلة

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

في حال استخدام رمز برمجي أصلي، يمكن أن يؤدي أي بيانات تتم قراءتها من الملفات أو تلقّيها عبر الشبكة أو تلقّيها من عملية اتصال بين العمليات (IPC) إلى حدوث مشكلة أمنية. المشاكل الأكثر شيوعًا هي تجاوز سعة المخزن المؤقت والاستخدام بعد التحرير وأخطاء الفرق بمقدار واحد. يوفر نظام التشغيل Android عددًا من التقنيات، مثل ASLR و"منع تنفيذ البيانات" (DEP)، التي تقلّل من إمكانية استغلال هذه الأخطاء، ولكنها لا تحل المشكلة الأساسية. يمكنك منع حدوث هذه الثغرات من خلال التعامل بعناية مع المؤشرات وإدارة المخازن المؤقتة.

تخضع اللغات الديناميكية المستندة إلى السلاسل، مثل JavaScript وSQL، أيضًا لمشاكل التحقّق من صحة الإدخال بسبب أحرف الإلغاء وإدخال البرامج النصية.

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

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

بيانات المستخدمين

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

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

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

إذا كان تطبيقك يتطلّب الوصول إلى بيانات حسّاسة، عليك تقييم ما إذا كنت بحاجة إلى نقلها إلى خادم أو ما إذا كان بإمكانك تنفيذ العملية على العميل. ننصحك بتنفيذ أي رمز باستخدام بيانات حساسة على الجهاز العميل لتجنُّب نقل بيانات المستخدم. عليك أيضًا التأكّد من عدم تعريض بيانات المستخدمين عن غير قصد للتطبيقات الأخرى على الجهاز من خلال عمليات IPC متساهلة للغاية أو ملفات قابلة للكتابة من قِبل الجميع أو مآخذ توصيل الشبكة. تُعدّ عملية IPC المتساهلة بشكل مفرط حالة خاصة من تسريب البيانات المحمية بإذن، كما هو موضّح في قسم طلبات الإذن.

إذا كان المعرّف الفريد العام (GUID) مطلوبًا، أنشئ رقمًا كبيرًا وفريدًا وخزِّنه. لا تستخدِم معرّفات الهواتف، مثل رقم الهاتف أو رقم IMEI، التي قد تكون مرتبطة بمعلومات شخصية. نتناول هذا الموضوع بمزيد من التفصيل في الصفحة حول أفضل الممارسات المتعلّقة بالمعرِّفات الفريدة.

يجب توخّي الحذر عند الكتابة في السجلات على الجهاز فقط. على أجهزة Android، تكون السجلات مصدرًا مشتركًا ومتاحة للتطبيق الذي لديه إذن READ_LOGS. على الرغم من أنّ بيانات سجلّ الهاتف مؤقتة ويتم محوها عند إعادة التشغيل، قد يؤدي التسجيل غير الملائم لمعلومات المستخدم إلى تسريب بيانات المستخدم إلى تطبيقات أخرى بدون قصد. بالإضافة إلى عدم تسجيل معلومات تكشف الهوية الشخصية، يجب الحدّ من استخدام السجلّات في التطبيقات المتاحة للجميع. لتنفيذ ذلك بسهولة، استخدِم علامات تصحيح الأخطاء وفئات Logمخصّصة بمستويات تسجيل قابلة للإعداد بسهولة.

عرض الويب

بما أنّ WebView يستهلك محتوى الويب الذي يمكن أن يتضمّن HTML وJavaScript، قد يؤدي الاستخدام غير السليم إلى حدوث مشاكل شائعة في أمان الويب، مثل النصوص البرمجية عبر المواقع الإلكترونية (إدخال JavaScript). يتضمّن نظام التشغيل Android عددًا من الآليات للحدّ من نطاق هذه المشاكل المحتملة من خلال تقييد إمكانية WebView بالحدّ الأدنى من الوظائف التي يتطلّبها تطبيقك.

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

استخدِم addJavaScriptInterface() بعناية خاصة، لأنّه يتيح لغة JavaScript استدعاء عمليات تكون عادةً مخصّصة لتطبيقات Android. في حال استخدامها، يجب عرض addJavaScriptInterface() فقط على صفحات الويب التي يمكن الوثوق بجميع البيانات التي يتم إدخالها فيها. في حال السماح بإدخال بيانات غير موثوق بها، قد تتمكّن JavaScript غير الموثوق بها من استدعاء طرق Android داخل تطبيقك. وبشكل عام، ننصح بعرض addJavaScriptInterface() فقط على JavaScript المضمّنة في حزمة APK لتطبيقك.

إذا كان تطبيقك يصل إلى بيانات حساسة باستخدام WebView، ننصحك باستخدام طريقة clearCache() لحذف أي ملفات مخزَّنة على الجهاز. يمكنك أيضًا استخدام عناوين من جهة الخادم، مثل no-store، للإشارة إلى أنّ أحد التطبيقات يجب ألا يخزّن محتوى معيّنًا مؤقتًا.

تستخدم الأجهزة التي تعمل بإصدارات أقدم من Android 4.4 (المستوى 19 لواجهة برمجة التطبيقات) إصدارًا من webkit يتضمّن عددًا من مشاكل الأمان. كحلّ بديل، إذا كان تطبيقك يعمل على هذه الأجهزة، يجب أن يؤكّد أنّ عناصر WebView تعرض محتوًى موثوقًا فقط. للتأكّد من عدم تعرُّض تطبيقك للثغرات الأمنية المحتملة في طبقة المقابس الآمنة، استخدِم عنصر الأمان Provider القابل للتحديث كما هو موضّح في مقالة تحديث موفّر الأمان للحماية من استغلال طبقة المقابس الآمنة. إذا كان تطبيقك يعرض محتوًى من الويب المفتوح، ننصحك بتوفير أداة العرض الخاصة بك حتى تتمكّن من إبقائها محدّثة بأحدث حِزم الأمان.

طلبات بيانات الاعتماد

تشكّل طلبات بيانات الاعتماد متجهًا للهجوم. في ما يلي بعض النصائح لمساعدتك في جعل طلبات بيانات الاعتماد في تطبيقات Android أكثر أمانًا.

تقليل التعرّض لبيانات الاعتماد

  • تجنُّب طلبات بيانات الاعتماد غير الضرورية: لجعل هجمات التصيّد الاحتيالي أكثر وضوحًا وتقليل فرص نجاحها، يجب تقليل عدد المرات التي يُطلب فيها من المستخدم تقديم بيانات الاعتماد. بدلاً من ذلك، استخدِم رمزًا مميّزًا للتفويض وجدِّده. اطلب الحدّ الأدنى من معلومات بيانات الاعتماد اللازمة للمصادقة والتفويض.
  • تخزين بيانات الاعتماد بأمان استخدِم Credential Manager لتفعيل المصادقة بدون كلمة مرور باستخدام مفاتيح المرور أو لتنفيذ عملية تسجيل دخول موحّدة باستخدام أنظمة مثل "تسجيل الدخول باستخدام حساب Google". إذا كان عليك استخدام مصادقة كلمات المرور التقليدية، لا تخزِّن معرّفات المستخدمين وكلمات المرور على الجهاز. بدلاً من ذلك، عليك إجراء المصادقة الأولية باستخدام اسم المستخدم وكلمة المرور اللذين يقدّمهما المستخدم، ثم استخدام رمز تفويض قصير الأمد خاص بالخدمة.
  • الحدّ من نطاق الأذونات: لا تطلب أذونات واسعة النطاق لمهمة لا تتطلّب سوى نطاق أضيق.
  • الحدّ من رموز الدخول: استخدام عمليات الرموز المميزة القصيرة الأمد وطلبات البيانات من واجهة برمجة التطبيقات
  • الحدّ من معدّلات المصادقة قد تشير طلبات المصادقة أو التفويض السريعة والمتتالية إلى هجوم القوة العمياء. يجب الحدّ من هذه المعدّلات إلى عدد مرات معقولة مع السماح في الوقت نفسه بتوفير تجربة تطبيق عملية وسهلة الاستخدام.

استخدام المصادقة الآمنة

  • تنفيذ مفاتيح المرور يمكنك تفعيل مفاتيح المرور كبديل أكثر أمانًا وسهولة في الاستخدام لكلمات المرور.
  • إضافة مقاييس حيوية توفير إمكانية استخدام المصادقة بالمقاييس الحيوية، مثل بصمة الإصبع أو التعرّف على الوجوه، لتعزيز الأمان
  • استخدام موفّري الهوية المتّحدة: تتوافق Credential Manager مع موفّري خدمات المصادقة الموحّدة، مثل تسجيل الدخول باستخدام حساب Google.
  • تشفير الاتصالات استخدِم بروتوكول HTTPS والتقنيات المشابهة لضمان حماية البيانات التي يرسلها تطبيقك عبر الشبكة.

اتّباع ممارسات آمنة لإدارة الحساب

  • ربط الخدمات التي يمكن الوصول إليها من خلال تطبيقات متعددة باستخدام AccountManager استخدِم الفئة AccountManager لاستدعاء خدمة مستندة إلى السحابة الإلكترونية، ولا تخزِّن كلمات المرور على الجهاز.
  • بعد استخدام AccountManager لاسترداد Account، استخدِم CREATOR قبل إدخال أي بيانات اعتماد حتى لا يتم إدخال بيانات الاعتماد عن غير قصد في التطبيق الخاطئ.
  • إذا كانت بيانات الاعتماد تُستخدَم فقط من خلال التطبيقات التي تنشئها، يمكنك التحقّق من التطبيق الذي يصل إلى AccountManager باستخدام checkSignatures. بدلاً من ذلك، إذا كان تطبيق واحد فقط يستخدم بيانات الاعتماد، يمكنك استخدام KeyStore للتخزين.

توخّي الحذر

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

إدارة مفاتيح واجهة برمجة التطبيقات

تُعدّ مفاتيح واجهة برمجة التطبيقات عنصرًا مهمًا في العديد من تطبيقات Android، فهي تتيح لها الوصول إلى الخدمات الخارجية وتنفيذ وظائف أساسية، مثل الاتصال بخدمات الخرائط والمصادقة وخدمات الطقس. ومع ذلك، يمكن أن يؤدي الكشف عن هذه المفاتيح الحسّاسة إلى عواقب وخيمة، بما في ذلك اختراق البيانات والوصول غير المصرَّح به والخسائر المالية. لمنع حدوث مثل هذه السيناريوهات، على المطوّرين تنفيذ استراتيجيات آمنة للتعامل مع مفاتيح واجهة برمجة التطبيقات طوال عملية التطوير.

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

هذا القسم مخصّص لمجموعتَين من مطوّري تطبيقات Android: المطوّرون الذين يعملون مع فِرق البنية الأساسية على مسار التسليم المتواصل، والمطوّرون الذين ينشرون تطبيقات مستقلة في "متجر Play". يوضّح هذا القسم أفضل الممارسات المتعلقة بكيفية التعامل مع مفاتيح واجهة برمجة التطبيقات، حتى يتمكّن تطبيقك من التواصل مع الخدمات بشكل آمن.

الإنشاء والتخزين

على المطوّرين التعامل مع تخزين مفتاح واجهة برمجة التطبيقات باعتباره عنصرًا مهمًا في حماية البيانات وخصوصية المستخدمين باستخدام نهج دفاعي متعدد الطبقات.

تخزين المفاتيح القوية

للحصول على أفضل أمان لإدارة المفاتيح، استخدِم Android Keystore، وشفِّر المفاتيح المخزَّنة باستخدام أداة قوية مثل Tink Java.

استبعاد التحكّم في المصدر

يجب عدم تضمين مفاتيح واجهة برمجة التطبيقات في مستودع الرموز البرمجية. تؤدي إضافة مفاتيح واجهة برمجة التطبيقات إلى رمز المصدر إلى تعريض المفاتيح لخطر الظهور في المستودعات المتاحة للجميع وأمثلة الرموز المشترَكة والملفات التي تتم مشاركتها عن طريق الخطأ. بدلاً من ذلك، استخدِم مكوّنات Gradle الإضافية، مثل secrets-gradle-plugin، للتعامل مع مفاتيح واجهة برمجة التطبيقات في مشروعك.

المفاتيح الخاصة بالبيئة

استخدِم مفاتيح واجهة برمجة تطبيقات منفصلة لبيئات التطوير والاختبار والإنتاج، إذا أمكن ذلك. استخدِم مفاتيح خاصة بكل بيئة لعزل كل بيئة، ما يقلّل من خطر الكشف عن بيانات الإنتاج ويسمح لك بإيقاف المفاتيح المخترَقة بدون التأثير في بيئة التشغيل الفعلي.

التحكّم في الاستخدام وإمكانية الوصول

تُعدّ ممارسات مفتاح واجهة برمجة التطبيقات الآمنة ضرورية لحماية واجهة برمجة التطبيقات والمستخدمين. في ما يلي كيفية إعداد مفاتيحك لتحقيق أفضل مستوى من الأمان:

  • إنشاء مفاتيح فريدة لكل تطبيق: استخدِم مفاتيح واجهة برمجة تطبيقات منفصلة لكل تطبيق للمساعدة في تحديد الوصول المخترَق وعزله.
  • تطبيق قيود على عناوين IP: إذا أمكن ذلك، احصر استخدام مفتاح واجهة برمجة التطبيقات على عناوين IP أو نطاقات معيّنة.
  • الحدّ من استخدام مفتاح التطبيق على الأجهزة الجوّالة: يمكنك الحدّ من استخدام مفتاح واجهة برمجة التطبيقات في تطبيقات معيّنة على الأجهزة الجوّالة من خلال تجميعها مع المفتاح أو استخدام شهادات التطبيق.
  • تسجيل الأنشطة المريبة ومراقبتها: عليك تنفيذ آليات لتسجيل استخدام واجهة برمجة التطبيقات ومراقبته من أجل رصد الأنشطة المريبة ومنع إساءة الاستخدام المحتملة.

ملاحظة: يجب أن توفّر خدمتك ميزات لحصر المفاتيح على حزمة أو منصة معيّنة. على سبيل المثال، يفرض Google Maps API قيودًا على إمكانية الوصول إلى المفتاح حسب اسم الحزمة ومفتاح التوقيع.

يوفّر بروتوكول OAuth 2.0 إطار عمل للسماح بالوصول إلى الموارد. تحدّد هذه المواصفة معايير طريقة تفاعل العملاء والخوادم، وتتيح الحصول على تفويض آمن. يمكنك استخدام OAuth 2.0 لحصر استخدام مفتاح واجهة برمجة التطبيقات على عملاء محدّدين، وتحديد نطاق الوصول لكي يقتصر كل مفتاح على الحد الأدنى من مستوى الوصول المطلوب للغرض المقصود منه.

تدوير المفاتيح وانتهاء صلاحيتها

للحدّ من مخاطر الوصول غير المصرَّح به من خلال الثغرات الأمنية غير المكتشفة في واجهات برمجة التطبيقات، من المهم تغيير مفاتيح واجهات برمجة التطبيقات بانتظام. يحدّد معيار ISO 27001 إطار عمل للامتثال يوضح عدد المرات التي يجب فيها تدوير المفاتيح. في معظم الحالات، تكون فترة تناوب المفاتيح التي تتراوح بين 90 يومًا و6 أشهر كافية. يمكن أن يساعدك تنفيذ نظام قوي لإدارة المفاتيح في تبسيط هذه العمليات، ما يؤدي إلى تحسين كفاءة تدوير المفاتيح واحتياجات انتهاء الصلاحية.

أفضل الممارسات العامة

  • استخدام بروتوكول SSL/HTTPS: استخدِم دائمًا بروتوكول HTTPS لتشفير طلبات واجهة برمجة التطبيقات.
  • تثبيت الشهادات: لتعزيز مستوى الأمان، يمكنك تنفيذ تثبيت الشهادات للتحقّق من الشهادات التي تُعتبر صالحة.
  • التحقّق من صحة بيانات أدخلها المستخدم وتنظيفها: تحقَّق من صحة بيانات أدخلها المستخدم ونظِّفها لمنع هجمات الحقن التي قد تكشف مفاتيح واجهة برمجة التطبيقات.
  • اتّباع أفضل ممارسات الأمان: اتّبِع أفضل ممارسات الأمان العامة في عملية التطوير، بما في ذلك تقنيات الترميز الآمن ومراجعات الرموز وفحص الثغرات الأمنية.
  • البقاء على اطّلاع: يمكنك البقاء على اطّلاع على آخر التهديدات الأمنية وأفضل الممارسات المتعلّقة بإدارة مفاتيح واجهة برمجة التطبيقات.
  • حِزم SDK محدَّثة: تأكَّد من تحديث حِزم SDK والمكتبات إلى أحدث إصدار.

تشفير

بالإضافة إلى توفير عزل البيانات وإتاحة التشفير الكامل لنظام الملفات وتوفير قنوات اتصالات آمنة، يوفّر نظام التشغيل Android مجموعة كبيرة من الخوارزميات لحماية البيانات باستخدام التشفير.

معرفة موفّري الأمان في بنية تشفير جافا (JCA) الذين يستخدمهم برنامجك حاوِل استخدام أعلى مستوى من تنفيذ إطار العمل الحالي الذي يمكنه دعم حالة الاستخدام. استخدِم موفّري الخدمات الذين توفّرهم Google بالترتيب الذي تحدّده Google، وذلك إذا كان ذلك منطبقًا.

إذا كنت بحاجة إلى استرداد ملف بأمان من موقع معروف على الشبكة، قد يكون معرّف موارد منتظم بسيط عبر HTTPS كافيًا ولا يتطلّب معرفة بالتشفير. إذا كنت بحاجة إلى نفق آمن، ننصحك باستخدام HttpsURLConnection أو SSLSocket بدلاً من كتابة بروتوكول خاص بك. إذا كنت تستخدم SSLSocket، يُرجى العِلم أنّه لا يجري عملية التحقّق من اسم المضيف. اطّلِع على تحذيرات بشأن استخدام SSLSocket مباشرةً.

إذا تبيّن لك أنّك بحاجة إلى تنفيذ البروتوكول الخاص بك، لا تنفّذ خوارزميات التشفير الخاصة بك. استخدِم خوارزميات التشفير الحالية، مثل عمليات تنفيذ AES وRSA المتوفّرة في فئة Cipher. بالإضافة إلى ذلك، اتّبِع أفضل الممارسات التالية:

  • استخدِم تشفير AES‏ 256 بت للأغراض التجارية. (في حال عدم توفّره، استخدِم AES‏ 128 بت).
  • استخدِم أحجام مفاتيح عامة تتراوح بين 224 و256 بت لتشفير المنحنى الإهليلجي (EC).
  • التعرّف على حالات استخدام أوضاع حظر CBC أو CTR أو GCM
  • تجنَّب إعادة استخدام IV/counter في وضع CTR. تأكَّد من أنّها عشوائية من الناحية التشفيرية.
  • عند استخدام التشفير، يجب تنفيذ السلامة باستخدام وضع CBC أو CTR مع إحدى الدالتين التاليتين:
    • HMAC-SHA1
    • HMAC-SHA-256
    • HMAC-SHA-512
    • وضع GCM

استخدِم أداة إنشاء أرقام عشوائية آمنة، SecureRandom، لتهيئة أي مفاتيح تشفير يتم إنشاؤها بواسطة KeyGenerator. يؤدي استخدام مفتاح لم يتم إنشاؤه باستخدام أداة إنشاء أرقام عشوائية آمنة إلى إضعاف قوة الخوارزمية بشكل كبير، وقد يسمح بشنّ هجمات غير متصلة بالإنترنت.

إذا كنت بحاجة إلى تخزين مفتاح لاستخدامه بشكل متكرر، استخدِم آلية، مثل KeyStore، توفّر تخزينًا واسترجاعًا طويل الأمد لمفاتيح التشفير.

التواصل البيني للعمليات

تحاول بعض التطبيقات تنفيذ عملية الاتصال بين العمليات باستخدام أساليب Linux التقليدية، مثل مآخذ توصيل الشبكة والملفات المشترَكة. ومع ذلك، ننصحك بدلاً من ذلك باستخدام وظائف نظام Android للتواصل بين العمليات، مثل Intent أو Binder أو Messenger مع Service وBroadcastReceiver. تتيح لك آليات الاتصال بين العمليات (IPC) في نظام التشغيل Android التحقّق من هوية التطبيق الذي يتصل بآلية الاتصال بين العمليات (IPC) وتحديد سياسة أمان لكل آلية من آليات الاتصال بين العمليات (IPC).

تتشارك العديد من عناصر الأمان في آليات الاتصال بين العمليات. إذا لم يكن الهدف من آلية الاتصال بين العمليات (IPC) هو أن تستخدمها تطبيقات أخرى، اضبط السمة android:exported على false في عنصر بيان المكوّن، مثل عنصر <service>. ويكون ذلك مفيدًا للتطبيقات التي تتضمّن عمليات متعددة ضمن معرّف المستخدم نفسه أو إذا قرّرت في مرحلة متأخرة من التطوير أنّك لا تريد عرض الوظائف كعملية اتصال بين العمليات (IPC)، ولكنّك لا تريد إعادة كتابة الرمز.

إذا كان بإمكان التطبيقات الأخرى الوصول إلى عملية الاتصال بين العمليات (IPC)، يمكنك تطبيق سياسة أمان باستخدام العنصر <permission>. إذا كانت عملية الاتصال بين العمليات (IPC) تتم بين تطبيقاتك الخاصة والموقَّعة باستخدام المفتاح نفسه، استخدِم إذن signature-level في android:protectionLevel.

الأهداف

بالنسبة إلى الأنشطة ومستقبِلات البث، فإنّ الأهداف هي الآلية المفضّلة للتواصل بين العمليات غير المتزامن على Android. استنادًا إلى متطلبات تطبيقك، يمكنك استخدام sendBroadcast أو sendOrderedBroadcast أو نية صريحة لمكوّن تطبيق معيّن. لأغراض أمنية، يُفضَّل استخدام النوايا الضمنية.

يُرجى العِلم أنّه يمكن استهلاك عمليات البث المنظَّمة من قِبل المستلِم، لذا قد لا يتم تسليمها إلى جميع التطبيقات. إذا كنت بصدد إرسال Intent يجب تسليمه إلى جهاز استقبال محدّد، عليك استخدام Intent صريح يعرّف جهاز الاستقبال بالاسم.

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

الخدمات

يتم غالبًا استخدام Service لتوفير وظائف يمكن للتطبيقات الأخرى استخدامها. يجب أن يحتوي كل فئة خدمة على بيان <service> مقابل في ملف البيان.

لا يتم تصدير الخدمات تلقائيًا ولا يمكن لأي تطبيق آخر استدعاؤها. ومع ذلك، إذا أضفت أي فلاتر أهداف إلى بيان الخدمة، سيتم تصديرها تلقائيًا. من الأفضل أن تحدّد السمة android:exported بشكل صريح للتأكّد من أنّها تتصرف بالطريقة التي تريدها. يمكن أيضًا حماية الخدمات باستخدام السمة android:permission. وبذلك، يجب أن تصرّح التطبيقات الأخرى عن عنصر <uses-permission> مطابق في بيانها لتتمكّن من بدء الخدمة أو إيقافها أو ربطها.

يمكن لإحدى الخدمات حماية طلبات IPC الفردية التي يتم إجراؤها فيها باستخدام الأذونات. يتم ذلك من خلال استدعاء checkCallingPermission() قبل تنفيذ عملية الاستدعاء. ننصحك باستخدام الأذونات التعريفية في ملف البيان، لأنّها أقل عرضة للسهو.

واجهتا Binder وMessenger

يُفضَّل استخدام Binder أو Messenger لتنفيذ عمليات الاتصال بين العمليات (IPC) بنمط RPC على Android. وتوفّر واجهات محدّدة جيدًا تتيح المصادقة المتبادلة لنقاط النهاية، إذا لزم الأمر.

ننصحك بتصميم واجهات تطبيقك بطريقة لا تتطلّب إجراء عمليات تحقّق من الأذونات الخاصة بالواجهة. لم يتم تعريف العنصرين Binder وMessenger في بيان التطبيق، وبالتالي لا يمكنك تطبيق الأذونات التعريفية عليهما مباشرةً. وعمومًا، ترث هذه المكوّنات الأذونات المحدّدة في بيان التطبيق الخاص بـ Service أو Activity الذي تم تنفيذها فيه. في حال إنشاء واجهة تتطلّب مصادقة و/أو عناصر تحكّم في الوصول، يجب إضافة عناصر التحكّم هذه صراحةً كرمز في واجهة Binder أو Messenger.

إذا كنت توفّر واجهة تتطلّب عناصر تحكّم في الوصول، استخدِم checkCallingPermission() للتحقّق مما إذا كان المتصل لديه الإذن المطلوب. ويُعدّ ذلك مهمًا بشكل خاص قبل الوصول إلى خدمة نيابةً عن المتصل، لأنّه يتم تمرير هوية تطبيقك إلى واجهات أخرى. إذا كنت تستدعي واجهة يوفّرها Service، قد يتعذّر استدعاء bindService() إذا لم يكن لديك إذن بالوصول إلى الخدمة المحدّدة. إذا كنت بحاجة إلى السماح لعملية خارجية بالتفاعل مع تطبيقك ولكن ليس لديها الأذونات اللازمة لذلك، يمكنك استخدام الطريقة clearCallingIdentity(). تُجري هذه الطريقة المكالمة إلى واجهة تطبيقك كما لو كان تطبيقك هو الذي يجري المكالمة وليس المتصل الخارجي. يمكنك استعادة أذونات المتصل لاحقًا باستخدام الطريقة restoreCallingIdentity().

لمزيد من المعلومات حول تنفيذ عملية الاتصال بين العمليات (IPC) باستخدام إحدى الخدمات، اطّلِع على الخدمات المرتبطة.

مستقبِلات البث

يتعامل BroadcastReceiver مع الطلبات غير المتزامنة التي يبدأها Intent.

يتم تلقائيًا تصدير أدوات الاستقبال ويمكن لأي تطبيق آخر استدعاؤها. إذا كان BroadcastReceiver مخصّصًا للاستخدام من قِبل تطبيقات أخرى، قد تحتاج إلى تطبيق أذونات الأمان على المستقبلات باستخدام العنصر <receiver> ضمن بيان التطبيق. يمنع ذلك التطبيقات التي لا تملك الأذونات المناسبة من إرسال Intent إلى BroadcastReceiver.

الأمان باستخدام الرمز الذي يتم تحميله بشكل ديناميكي

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

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

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

الأمان في جهاز افتراضي

‫Dalvik هو جهاز Android الافتراضي (VM) لبيئة التشغيل. تم تصميم Dalvik خصيصًا لنظام التشغيل Android، ولكن العديد من المخاوف المتعلقة بالرموز الآمنة في الأجهزة الافتراضية الأخرى تنطبق أيضًا على Android. بشكل عام، لا داعي للقلق بشأن مشاكل الأمان المتعلقة بالجهاز الافتراضي. يعمل تطبيقك في بيئة آمنة ومعزولة، وبالتالي لا يمكن للعمليات الأخرى على النظام الوصول إلى الرمز أو البيانات الخاصة بك.

إذا كنت مهتمًا بمعرفة المزيد حول أمان الآلات الافتراضية، يمكنك الاطّلاع على بعض المراجع المتوفرة حول هذا الموضوع. في ما يلي اثنان من المراجع الأكثر شيوعًا:

يركّز هذا المستند على الجوانب الخاصة بنظام التشغيل Android أو المختلفة عن بيئات الأجهزة الافتراضية الأخرى. بالنسبة إلى المطوّرين الذين لديهم خبرة في برمجة الآلات الافتراضية في بيئات أخرى، هناك مشكلتان رئيسيتان قد تختلفان بشأن كتابة التطبيقات لنظام Android:

  • تعمل بعض الأجهزة الافتراضية، مثل JVM أو وقت تشغيل .NET، كحدود أمان، ما يؤدي إلى عزل الرمز البرمجي عن إمكانات نظام التشغيل الأساسي. على نظام التشغيل Android، لا تشكّل آلة Dalvik الافتراضية حدودًا أمنية، بل يتم تنفيذ وضع الحماية للتطبيق على مستوى نظام التشغيل، وبالتالي يمكن أن تتوافق آلة Dalvik مع الرمز البرمجي الأصلي في التطبيق نفسه بدون أي قيود أمنية.
  • نظرًا لمساحة التخزين المحدودة على الأجهزة الجوّالة، من الشائع أن يريد المطوّرون إنشاء تطبيقات معيارية واستخدام تحميل الفئات الديناميكي. عند إجراء ذلك، يجب مراعاة المصدر الذي تسترد منه منطق تطبيقك والمكان الذي تخزّنه فيه محليًا. لا تستخدِم تحميل الفئات الديناميكية من مصادر لم يتم التحقّق منها، مثل مصادر الشبكة غير الآمنة أو وحدة التخزين الخارجية، لأنّه قد يتم تعديل هذا الرمز البرمجي ليشمل سلوكًا ضارًا.

الأمان في الرموز البرمجية الأصلية

بشكل عام، ننصح باستخدام حزمة تطوير البرامج (SDK) لنظام التشغيل Android لتطوير التطبيقات، بدلاً من استخدام الرمز البرمجي الأصلي مع Android NDK. تكون التطبيقات التي تم إنشاؤها باستخدام رموز برمجية أصلية أكثر تعقيدًا وأقل قابلية للنقل، ومن المرجّح أن تتضمّن أخطاء شائعة لتلف الذاكرة، مثل تجاوز سعة المخزن المؤقت.

تم إنشاء Android باستخدام نواة Linux، لذا فإنّ الإلمام بأفضل ممارسات أمان تطوير Linux مفيد بشكل خاص إذا كنت تستخدم رمزًا برمجيًا أصليًا. لا يتناول هذا المستند ممارسات الأمان في نظام التشغيل Linux، ولكن أحد المراجع الأكثر شيوعًا هو Secure Programming HOWTO - Creating Secure Software.

يتمثّل أحد الفروق المهمة بين Android ومعظم بيئات Linux في وضع الحماية للتطبيقات. على Android، يتم تشغيل جميع التطبيقات في وضع الحماية الخاص بالتطبيق، بما في ذلك التطبيقات المكتوبة باستخدام الرموز البرمجية الأصلية. بالنسبة إلى المطوّرين الذين يعرفون نظام التشغيل Linux، يمكنهم التفكير في الأمر على أنّ كل تطبيق يحصل على معرّف مستخدم فريد (UID) مع أذونات محدودة جدًا. تمت مناقشة ذلك بتفصيل أكبر في نظرة عامة على أمان Android، ويجب أن تكون على دراية بأذونات التطبيقات حتى إذا كنت تستخدم رمزًا برمجيًا أصليًا.