测试和调试功能
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
OWASP 类别:MASVS-CODE:代码质量
概览
发布的正式版 build 中如果包含测试或调试功能,可能会对应用的安全状况产生负面影响。这些功能旨在帮助开发者在新版本发布之前或之后发现和识别预期应用用例中的 bug,不应允许公开访问。
测试/调试功能的示例如下:
- 隐藏的菜单
- 用于启用调试日志的选项
- 用于更改应用流程的选项
- 用于规避付款或订阅流程的选项
- 用于规避身份验证的选项
- 针对应用专用 activity 的测试
恶意用户可能会利用上述所有选项来更改应用的预期流程或检索系统信息,从而有针对性地调整进一步的攻击方式。
让测试或调试功能保持公开所带来的风险可能会因与调试功能本身相关的操作而有所不同。
应用面临的另一个风险区域是在 AndroidManifest.xml 元素 <application>
中设置的 android:debuggable 属性。如果部署的正式版应用设置了 android:debuggable 一文中所述的值,那么恶意用户便可访问原本无法访问的管理资源。
影响
恶意用户如果与正式版 build 中的测试或调试功能进行了互动,可能会导致无法预料的结果。相关操作造成的影响与分配给相应功能的权限直接相关。权限越高,主动利用的影响就越大。应用中的测试或调试功能可用于规避多项保护机制、绕过付费墙、检索系统/用户相关信息,或触发测试活动。
缓解措施
避免使用调试组件
绝不应在正式版应用组件(如 activity、广播接收器、服务或 content provider)中实现测试或调试功能,因为这些功能一旦被导出,设备上的任何其他进程便可运行这些功能。将调试组件设置为未导出 (android:exported="false")并不构成对这些功能的有效保护,因为如果启用了调试选项,已取得 root 权限的设备仍然可以通过 Android 调试桥 (ADB) 工具来执行调试功能。
仅限预演版 build 使用调试或测试功能
应仅限一组有限的预演版 build 来执行应用内的任何测试或调试功能,以便仅允许开发者在受控环境中调试或测试应用功能。为此,可以创建应用的专用测试或调试 build 并为其创建高级插桩测试,以确保所有测试或调试功能都在隔离的版本上运行。
实现自动化界面测试
对应用运行测试时,请选择使用自动化界面测试,因为这些测试可重复,可在分隔的环境中执行,并且不易出现人为错误。
资源
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2023-12-13。
[null,null,["最后更新时间 (UTC):2023-12-13。"],[],[],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/)"]]