테스트 및 디버그 기능
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
OWASP 카테고리: MASVS-CODE: 코드 품질
개요
테스트 또는 디버그 기능이 포함된 프로덕션 빌드를 출시하면 애플리케이션의 보안 상태에 부정적인 영향을 미칠 수 있습니다. 이러한 기능은 개발자가 새 버전 출시 전이나 출시 후에 의도한 애플리케이션 사용 사례에서 버그를 발견하고 식별하는 데 사용되며 공개적으로 액세스 가능해서는 안 됩니다.
테스트/디버그 기능의 예는 다음과 같습니다.
- 숨겨진 메뉴
- 디버그 로그 사용 설정 옵션
- 애플리케이션 흐름을 변경하는 옵션
- 결제 또는 구독 절차를 우회하는 옵션
- 인증을 우회하는 옵션
- 애플리케이션별 활동 테스트
위의 모든 항목은 악의적인 사용자가 애플리케이션의 의도된 흐름을 변경하거나, 시스템 정보를 가져와 추가 공격을 맞춤화하는 데 활용할 수 있습니다.
노출된 테스트 또는 디버그 기능을 그대로 두면 발생하는 위험은 디버그 기능 자체와 관련된 작업에 따라 달라질 수 있습니다.
애플리케이션의 또 다른 위험 영역은 AndroidManifest.xml 요소 <application>
내에 설정된 android:debuggable 속성입니다. android:debuggable 도움말에 보고된 것처럼 앞서 언급한 값이 설정된 프로덕션 애플리케이션을 배포하면 악의적인 사용자가 다르게는 액세스할 수 없는 관리 리소스에 액세스할 수 있습니다.
영향
프로덕션 빌드의 테스트 또는 디버그 기능과 상호작용하는 악의적인 사용자로 인해 예기치 않은 결과가 발생할 수 있습니다. 모든 작업의 영향은 기능에 할당된 권한과 직접 관련이 있습니다. 권한이 높을수록 활성 악용이 미칠 수 있는 영향도 커집니다. 애플리케이션 내의 이러한 기능은 다수의 보호 기능을 우회하거나 페이월을 우회하거나 시스템 또는 사용자 관련 정보를 가져오거나 테스트 활동을 트리거하는 데 사용될 수 있습니다.
완화 조치
디버그 구성요소 사용 피하기
테스트 또는 디버그 기능은 활동, broadcast receiver, 서비스 또는 콘텐츠 제공자와 같은 프로덕션 애플리케이션 구성요소 내에 구현하면 안 됩니다. 내보내는 경우 기기의 다른 프로세스에서 실행할 수 있기 때문입니다.
디버그 구성요소를 내보내지 않음으로 설정(android:exported="false")해도 기능을 유효하게 보호하지 않습니다. 디버그 옵션이 사용 설정된 경우 루팅된 기기가 여전히 Android 디버그 브리지(ADB) 도구를 통해 이를 실행할 수 있기 때문입니다.
디버그 또는 테스트 기능을 스테이징 빌드로 제한
개발자만 통제된 환경에서 애플리케이션 기능을 디버그하거나 테스트할 수 있도록, 애플리케이션 내에서 테스트 또는 디버그 기능의 실행은 제한된 스테이징 빌드 집합으로만 제한해야 합니다.
이는 애플리케이션의 전용 테스트 또는 디버그 빌드와 고급 계측 테스트를 만들어 모든 테스트 또는 디버그 기능이 격리된 버전에서 실행되도록 함으로써 달성할 수 있습니다.
자동화된 UI 테스트 구현
애플리케이션에서 테스트를 실행하는 경우 자동화된 UI 테스트를 선택하세요. 반복 가능하고, 분리된 환경에서 실행할 수 있으며, 인적 오류가 발생하지 않습니다.
리소스
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2023-12-08(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2023-12-08(UTC)"],[],[],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/)"]]