اختبار الميزات وتصحيح الأخطاء
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
فئة OWASP: MASVS-CODE: جودة الرمز
نظرة عامة
قد يؤدي إصدار إصدارات نهائية تتضمّن ميزات "الاختبار" أو "تصحيح الأخطاء" إلى التأثير سلبًا في مستوى أمان التطبيق. تُستخدَم هذه الوظائف لمساعدة المطوّرين في اكتشاف الأخطاء وتحديدها ضمن حالات استخدام التطبيق المقصودة قبل إصدار إصدار جديد أو بعده، ويجب ألا تكون متاحة للجميع.
في ما يلي أمثلة على ميزات الاختبار/ تصحيح الأخطاء:
- القوائم المخفية
- خيارات تفعيل سجلّات تصحيح الأخطاء
- خيارات لتغيير سير التطبيق
- خيارات للتحايل على عمليات الدفع أو الاشتراك
- خيارات لتجاوز المصادقة
- اختبارات للأنشطة الخاصة بالتطبيق
يمكن للمستخدم الضار الاستفادة من كل ما سبق لتغيير المسار المقصود للتطبيق أو استرداد معلومات النظام لتخصيص المزيد من الهجمات.
قد يختلف مستوى الخطورة الناتج عن ترك ميزات "الاختبار" أو "تصحيح الأخطاء" مكشوفة حسب الإجراء المرتبط بإمكانات تصحيح الأخطاء نفسها.
هناك مجال آخر يشكّل خطرًا على التطبيق وهو السمة android:debuggable
المعيّنة ضمن العنصر <application> في ملف AndroidManifest.xml. كما هو موضّح في مقالة android:debuggable،
يسمح نشر تطبيق مخصّص للإنتاج مع ضبط القيمة المذكورة أعلاه
للمستخدمين الضارين بالوصول إلى موارد إدارية لا يمكن الوصول إليها
في الحالات الأخرى.
التأثير
يمكن أن يؤدي تفاعل مستخدم ضار مع ميزة "الاختبار" أو "تصحيح الأخطاء" في إصدار علني إلى نتائج غير متوقّعة. ويرتبط تأثير أي إجراء بشكل مباشر بالأذونات الممنوحة للميزة. وكلما زادت الأذونات، زاد التأثير الذي يمكن أن يحدثه الاستغلال النشط. ويمكن استخدام هذه الوظائف داخل التطبيق للتحايل على عدد من وسائل الحماية أو تجاوز جدران الحماية أو استرداد معلومات متعلقة بالنظام أو المستخدم أو بدء أنشطة الاختبار.
إجراءات التخفيف
تجنُّب استخدام مكوّنات تصحيح الأخطاء
يجب عدم تنفيذ وظائف الاختبار أو تصحيح الأخطاء في مكونات التطبيق المخصّصة للإنتاج، مثل الأنشطة أو أدوات استقبال البث أو الخدمات أو موفّري المحتوى، لأنّه في حال تصديرها، يمكن لأي عملية أخرى على الجهاز تشغيلها.
لا يشكّل ضبط مكوّن تصحيح الأخطاء على أنّه غير مُصدَّر
(android:exported="false") حماية صالحة للإمكانات، لأنّه لا يزال بإمكان أي جهاز مزوّد بحق الوصول إلى الجذر تنفيذها من خلال أداة "جسر تصحيح أخطاء Android" (ADB) إذا تم تفعيل خيار تصحيح الأخطاء.
حصر ميزات تصحيح الأخطاء أو الاختبار على الإصدارات التجريبية
يجب أن يقتصر تنفيذ أي وظيفة اختبار أو تصحيح أخطاء داخل التطبيقات على مجموعة محدودة فقط من إصدارات مرحلة الاختبار، وذلك للسماح للمطوّرين فقط بتصحيح الأخطاء أو اختبار ميزات التطبيق في بيئة خاضعة للرقابة.
ويمكن الحصول على ذلك من خلال إنشاء إصدار مخصّص للاختبار أو تصحيح الأخطاء في التطبيق، وإجراء اختبارات متقدّمة باستخدام أدوات القياس لضمان تشغيل أي ميزة اختبار أو تصحيح أخطاء على إصدار معزول.
تنفيذ اختبارات واجهة المستخدم المبرمَجة
عند إجراء اختبارات على أحد التطبيقات، ننصحك باختيار اختبارات واجهة المستخدم المبرمَجة لأنّها قابلة للتكرار ويمكن تنفيذها في بيئة منفصلة ولا تكون عرضة للأخطاء البشرية.
المراجع
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Test and debug features\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\n\nOverview\n--------\n\nReleasing production builds that include Testing or Debug features can\nnegatively impact the security posture of the application. These functionalities\nare used to help developers discover and identify bugs within intended\napplication use cases prior to, or after a new version release, and shouldn't\nbe publicly accessible.\n\nExamples of Testing/ Debug features are:\n\n- Hidden menus\n- Options to enable debug logs\n- Options to alter application flow\n- Options to circumvent payment or subscription processes\n- Options to circumvent authentication\n- Tests for application-specific activities\n\nAll the preceding can be leveraged by a malicious user in order to alter the\napplication's intended flow or retrieve system information to tailor further\nattacks.\n\nThe risk introduced by leaving exposed Testing or Debug features may vary\naccording to the action associated with the debug capabilities itself.\n\nAnother area of risk for the application is the attribute **android:debuggable**\nset within the AndroidManifest.xml element **`\u003capplication\u003e`** . As reported in\nthe [**android:debuggable**](/topic/security/risks/android-debuggable) article,\ndeploying a production application with the aforementioned value set, allows\nmalicious users to access administrative resources that are otherwise\ninaccessible.\n\nImpact\n------\n\nA malicious user interacting with a Testing or Debug feature in a production\nbuild can lead to unexpected results. The impact of any action is directly\nconnected with the permissions assigned to the feature. The higher the\npermissions, the higher the impact that an active exploitation can have. Such\nfunctionalities within an application can be used to circumvent a number of\nprotections, bypass paywalls, retrieve system or user related information, or\ntrigger testing activities.\n\nMitigations\n-----------\n\n### Avoid using debug components\n\nTest or debug functionalities should never be implemented within production\napplication components such as activities, broadcast receivers, services or\ncontent providers since, if exported, can be run by any other process on the\ndevice.\nSetting the debug component as not exported\n([**android:exported=\"false\"**](/topic/security/risks/android-exported)) does\nnot constitute a valid protection for the capabilities since any rooted device\ncan still execute it through the Android Debug Bridge (ADB) tool if the debug\noption is enabled.\n\n### Limit debug or test features to staging builds\n\nThe execution of any test or debug function within applications should be\nlimited only to a restricted set of Staging builds to allow only developers to\ndebug or test application's features in a controlled environment.\nThis can be obtained by creating a dedicated test or debug build of the\napplication and advanced instrumented tests for it in order to ensure that any\ntest or debug feature is run on an isolated version.\n\n### Implement automated UI tests\n\nWhen running tests on an application, opt for automated UI tests since they are\nrepeatable, can be executed in a separated environment and are not prone to\nhuman errors.\n\nResources\n---------\n\n- [Dev guidance on advanced testing setups](/studio/test/advanced-test-setup)\n- [Dev guidance on automating UI tests](/training/testing/instrumented-tests/ui-tests)\n- [android:debuggable](/topic/security/risks/android-debuggable)\n- [android:exported](/topic/security/risks/android-exported)\n- [Debuggable Apps in Android Market](https://labs.withsecure.com/publications/debuggable-apps-in-android-market)\n- [Can debug code cause security vulnerabilities?](https://www.coderskitchen.com/an-debug-code-cause-security-vulnerabilities/)"]]
