ویژگی های تست و اشکال زدایی
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
دسته OWASP: MASVS-CODE: کیفیت کد
نمای کلی
انتشار بیلدهای تولیدی که شامل ویژگی‌های Testing یا Debug هستند، می‌تواند بر وضعیت امنیتی برنامه تأثیر منفی بگذارد. این قابلیت‌ها برای کمک به توسعه‌دهندگان برای کشف و شناسایی اشکالات در موارد استفاده برنامه مورد نظر قبل یا بعد از انتشار نسخه جدید استفاده می‌شوند و نباید برای عموم قابل دسترسی باشند.
نمونه هایی از ویژگی های تست / اشکال زدایی عبارتند از:
- منوهای مخفی
- گزینه‌هایی برای فعال کردن گزارش‌های اشکال‌زدایی
- گزینه هایی برای تغییر جریان برنامه
- گزینه هایی برای دور زدن فرآیندهای پرداخت یا اشتراک
- گزینه هایی برای دور زدن احراز هویت
- تست هایی برای فعالیت های کاربردی خاص
همه موارد قبلی را می توان توسط یک کاربر مخرب به منظور تغییر جریان مورد نظر برنامه یا بازیابی اطلاعات سیستم برای سفارشی سازی حملات بیشتر مورد استفاده قرار داد.
خطری که با در معرض قرار دادن ویژگی‌های تست یا اشکال‌زدایی ایجاد می‌شود ممکن است بسته به عملکرد مربوط به خود قابلیت‌های اشکال‌زدایی متفاوت باشد.
یکی دیگر از حوزه‌های خطر برای برنامه، مجموعه ویژگی android:debuggable در عنصر AndroidManifest.xml <application> است. همانطور که در مقاله android:debuggable گزارش شده است، استقرار یک برنامه تولیدی با مجموعه مقادیر ذکر شده، به کاربران مخرب اجازه می دهد تا به منابع مدیریتی دسترسی پیدا کنند که در غیر این صورت غیرقابل دسترسی هستند.
تاثیر
یک کاربر مخرب در تعامل با یک ویژگی Testing یا Debug در یک ساخت تولید می تواند منجر به نتایج غیرمنتظره شود. تأثیر هر عمل مستقیماً با مجوزهای اختصاص داده شده به ویژگی مرتبط است. هر چه مجوزها بیشتر باشد، تأثیری که یک بهره برداری فعال می تواند داشته باشد، بیشتر می شود. چنین قابلیت‌هایی در یک برنامه کاربردی می‌توانند برای دور زدن تعدادی از حفاظت‌ها، دور زدن دیوارهای پرداخت، بازیابی اطلاعات مربوط به سیستم یا کاربر، یا راه‌اندازی فعالیت‌های آزمایشی مورد استفاده قرار گیرند.
اقدامات کاهشی
از استفاده از اجزای اشکال زدایی خودداری کنید
عملکردهای تست یا اشکال‌زدایی هرگز نباید در اجزای برنامه تولید مانند فعالیت‌ها، گیرنده‌های پخش، خدمات یا ارائه‌دهندگان محتوا پیاده‌سازی شوند، زیرا در صورت صادر شدن، می‌توانند توسط هر فرآیند دیگری در دستگاه اجرا شوند. تنظیم مؤلفه اشکال‌زدایی به‌عنوان صادر نشده ( android:exported="false" ) یک محافظت معتبر برای قابلیت‌ها به حساب نمی‌آید زیرا اگر گزینه اشکال‌زدایی فعال باشد، هر دستگاه روت شده همچنان می‌تواند آن را از طریق ابزار Android Debug Bridge (ADB) اجرا کند.
ویژگی‌های اشکال‌زدایی یا آزمایش را به ساخت‌های مرحله‌بندی محدود کنید
اجرای هر تست یا عملکرد اشکال زدایی در برنامه ها باید فقط به مجموعه ای محدود از ساخت های Staging محدود شود تا فقط توسعه دهندگان بتوانند ویژگی های برنامه را در یک محیط کنترل شده اشکال زدایی یا آزمایش کنند. این را می توان با ایجاد یک ساخت تست یا اشکال زدایی اختصاصی از برنامه و تست های ابزار پیشرفته برای آن به منظور اطمینان از اجرای هر تست یا ویژگی اشکال زدایی در نسخه ایزوله به دست آورد.
اجرای تست های UI خودکار
هنگام اجرای آزمایش‌ها بر روی یک برنامه، تست‌های UI خودکار را انتخاب کنید زیرا قابل تکرار هستند، می‌توانند در یک محیط جداگانه اجرا شوند و مستعد خطاهای انسانی نیستند.
منابع
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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/)"]]
