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

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

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

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

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

المصادقة

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

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

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

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

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

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

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

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

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

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

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

بشكلٍ تلقائي، لا يمكن الوصول إلى الملفات التي تنشئها على وحدة التخزين الداخلية إلا من خلال تطبيقك. ينفّذ نظام التشغيل 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 من خلال تسلسل بيانات المستخدمين قبل إرسالها إلى الطريقة.

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

الأذونات

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

طلبات الحصول على الأذونات

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

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

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

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

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

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

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

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

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

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

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

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

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

شبكة بروتوكول الإنترنت

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WebView

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

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

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

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

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

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

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

تقليل إمكانية الوصول إلى بيانات الاعتماد

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

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

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

ممارسة إدارة الحسابات بأمان

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

توخّي الحذر

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

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

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

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

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

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

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

تخزين مفاتيح التشفير بشكل آمن

للحصول على أفضل مستوى من أمان إدارة المفاتيح، استخدِم ملف تخزين مفاتيح Android وتشفير المفاتيح المخزّنة باستخدام أداة فعّالة مثل 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.

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

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

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

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

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

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

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

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

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

مكان ووقت الاستماع إلى الموسيقى

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

تحذير: إذا كنت تستخدم نية للربط بعنصر **Service**، استخدِم نية واضحة للحفاظ على أمان تطبيقك. يشكّل استخدام نية ضمنية لبدء خدمة خطرًا على الأمان، لأنّه لا يمكنك التأكّد من الخدمة التي ستستجيب للنية ولا يمكن للمستخدم معرفة الخدمة التي سيتم تشغيلها. بدءًا من الإصدار Android 5.0 (المستوى 21 لواجهة برمجة التطبيقات)، يُرسِل النظام استثناءً في حال استدعاء **bindService()** باستخدام نية ضمنية.

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

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

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

الخدمات

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

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

ملاحظة: إذا كان تطبيقك يستهدف الإصدار 5.0 من نظام التشغيل Android (المستوى 21 من واجهة برمجة التطبيقات) أو إصدارًا أحدث، استخدِم الرمز **JobScheduler** لتنفيذ الخدمات التي تعمل في الخلفية.

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

تحذير: لا تخلط بين أذونات العميل والخادم، وتأكَّد من أنّ التطبيق المُستخدَم في الاتصال لديه الأذونات المناسبة وتأكَّد من منح الأذونات نفسها للتطبيق المُستخدَم في الاتصال.

واجهات Binder وMessenger

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

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

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

لمزيد من المعلومات عن تنفيذ تقنية IPC مع خدمة، اطّلِع على الخدمات المقيّدة.

أجهزة استقبال البث

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

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

الأمان باستخدام الرمز البرمجي المحمَّل ديناميكيًا

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

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

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

الأمان في آلة افتراضية

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

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

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

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

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

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

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

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