Port MASTG test 0039 (by @guardsquare)

techniques/android/MASTG-TECH-0117.md

@@ -0,0 +1,47 @@
+--- 
+title: Obtaining Information from the AndroidManifest
+platform: android 
+---
+
+Multiple ways exist to view the contents of the AndroidManifest:
+
+## Using @MASTG-TOOL-0011
+
+The full AndroidManifest can be extracted using @MASTG-TOOL-0011:
+
+```sh
+$ apktool d myapp.apk -s -o apktooled_app
+I: Using Apktool 2.7.0 on myapp.apk
+I: Loading resource table...
+I: Decoding AndroidManifest.xml with resources...
+I: Loading resource table from file: /home/.local/share/apktool/framework/1.apk
+I: Regular manifest package...
+I: Decoding file-resources...
+I: Decoding values */* XMLs...
+I: Copying raw classes.dex file...
+I: Copying assets and libs...
+I: Copying unknown files...
+I: Copying original files...
+I: Copying META-INF/services directory
+```
+
+`-s` skips baksmaliing the dex files and is faster.
+
+The AndroidManifest.xml is extracted and decoded to `apktooled_app/AndroidManifest.xml`, where you can simply open and view it.
+
+## Using @MASTG-TOOL-0124
+
+If you are only interested in specific values of the manifest, you can use alternatively use @MASTG-TOOL-0124. Please note that the output is not a XML file.
+
+Viewing all contents of the AndroidManifest can be performed with:
+
+```bash
+$ aapt d badging MASTG-DEMO-0001.apk                     
+package: name='org.owasp.mastestapp' versionCode='1' versionName='1.0' platformBuildVersionName='14' platformBuildVersionCode='34' compileSdkVersion='34' compileSdkVersionCodename='14'
+sdkVersion:'29'
+targetSdkVersion:'34'
+uses-permission: name='android.permission.INTERNET'
+uses-permission: name='org.owasp.mastestapp.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION'
+application-label:'MASTestApp'
+...
+```

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0226.md

@@ -0,0 +1,32 @@
+---
+title: Debuggable Flag Enabled in the AndroidManifest
+platform: android
+id: MASTG-TEST-0226
+type: [static]
+weakness: MASWE-0067
+---
+
+## Overview
+
+This test case checks if the app has the `debuggable` flag ([`android:debuggable`](https://developer.android.com/guide/topics/manifest/application-element#debug)) set to `true` in the `AndroidManifest.xml`. When this flag is enabled, it allows the app to be debugged enabling attackers to inspect the app’s internals, bypass security controls, or manipulate runtime behavior.
+
+Although having the `debuggable` flag set to `true` [is not considered a direct vulnerability](https://developer.android.com/privacy-and-security/risks/android-debuggable), it significantly increases the attack surface by providing unauthorized access to app data and resources, particularly in production environments.
+
+## Steps
+
+1. Obtain the `AndroidManifest.xml` file using @MASTG-TECH-0117.
+2. Search for the `debuggable` flag:
+    - Look for `android:debuggable` if analyzing raw XML using tools like @MASTG-TOOL-0011.
+    - Look for `application-debuggable` if using @MASTG-TOOL-0124.
+
+## Observation
+
+The output should explicitly show whether the `debuggable` flag is set (`true` or `false`). If the flag is not specified, it is treated as `false` by default for release builds.
+
+## Evaluation
+
+The test case fails if the `debuggable` flag is explicitly set to `true`. This indicates that the app is configured to allow debugging, which is inappropriate for production environments.
+
+To mitigate this issue, ensure the debuggable flag in the AndroidManifest.xml is set to false for all release builds.
+
+**Note:** Disabling debugging via the `debuggable` flag is an important first step but does not fully protect the app from advanced attacks. Skilled attackers can enable debugging through various means, such as binary patching (see @MASTG-TECH-0038) to allow attachment of a debugger or the use of binary instrumentation tools like @MASTG-TOOL-0001 to achieve similar capabilities. For apps requiring a higher level of security, consider implementing anti-debugging techniques as an additional layer of defense. Refer to @MASWE-0101 for detailed guidance.

tests-beta/android/MASVS-RESILIENCE/MASTG-TEST-0227.md

@@ -0,0 +1,53 @@
+---
+title: Debugging Enabled for WebViews
+platform: android
+id: MASTG-TEST-0227
+type: [static]
+weakness: MASWE-0067
+---
+
+## Overview
+
+The `WebView.setWebContentsDebuggingEnabled(true)` API enables debugging for **all** WebViews in the application. This feature can be useful during development, but introduces significant security risks if left enabled in production. When enabled, a connected PC can debug, eavesdrop, or modify communication within any WebView in the application. See the ["Android Documentation"](https://developer.chrome.com/docs/devtools/remote-debugging/webviews/#configure_webviews_for_debugging) for more details.
+
+Note that this flag works independently of the `debuggable` attribute in the `AndroidManifest.xml` (see @MASTG-TEST-0226). Even if the app is not marked as debuggable, the WebViews can still be debugged by calling this API.
+
+## Steps
+
+1. Run @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 on the app binary and look for uses of:
+    - `WebView.setWebContentsDebuggingEnabled` being set to `true`.
+    - `ApplicationInfo.FLAG_DEBUGGABLE`.
+
+## Observation
+
+The output should list:
+
+- All locations where `WebView.setWebContentsDebuggingEnabled` is called with `true` at runtime.
+- Any references to `ApplicationInfo.FLAG_DEBUGGABLE`.
+
+## Evaluation
+
+The test case fails if `WebView.setWebContentsDebuggingEnabled(true)` is called unconditionally or in contexts where the `ApplicationInfo.FLAG_DEBUGGABLE` flag is not checked.
+
+To mitigate this issue:
+
+- Set `WebView.setWebContentsDebuggingEnabled` to `false` in production, or remove the calls entirely if they are unnecessary.
+- If WebView debugging is required during development, ensure it is enabled only when the app is in a debuggable state by [checking the `ApplicationInfo.FLAG_DEBUGGABLE` flag at runtime](https://developer.chrome.com/docs/devtools/remote-debugging/webviews/#configure_webviews_for_debugging).
+
+For example:
+
+```kotlin
+if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
+    if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
+    { WebView.setWebContentsDebuggingEnabled(true); }
+}
+```
+
+**Note:** Disabling WebView debugging this way helps protect an app already running on a device. For an attacker to exploit WebView debugging, they must have physical access to the device (e.g., a stolen or test device) or remote access through malware or other malicious means. Additionally, the device must typically be unlocked, and the attacker would need to know the device PIN, password, or biometric authentication to gain full control and connect debugging tools like `adb` or Chrome DevTools.
+
+However, disabling WebView debugging does not eliminate all attack vectors. An attacker could:
+
+1. Patch the app to add calls to these APIs (see @MASTG-TECH-0038), then repackage and re-sign it (see @MASTG-TECH-0039).
+2. Use runtime method hooking (see @MASTG-TECH-0043) to enable WebView debugging dynamically at runtime.
+
+Disabling WebView debugging serves as one layer of defense to reduce risks but should be combined with other security measures.

tests/android/MASVS-RESILIENCE/MASTG-TEST-0039.md

@@ -7,6 +7,9 @@ platform: android
 title: Testing whether the App is Debuggable
 masvs_v1_levels:
 - R
+status: deprecated
+covered_by: [MASTG-TEST-0226,MASTG-TEST-0227]
+deprecation_note: New version available in MASTG V2
 ---
 
 ## Overview

tools/android/MASTG-TOOL-0124.md

@@ -0,0 +1,7 @@
+---
+title: aapt2
+platform: android
+source: https://developer.android.com/tools/aapt2
+---
+
+[aapt2](https://developer.android.com/tools/aapt2), available in Android SDK Build Tools since revision 26.0.2, is contained in the @MASTG-TOOL-0006 at `[SDK-Path]/build-tools/[version]/aapt2` and can be used, for example, to examine the contents of the AndroidManifest file.