update tests content

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

@@ -8,22 +8,25 @@ weakness: MASWE-0067
 
 ## Overview
 
-This test case checks if the application has the debuggable flag ([`android:debuggable`](https://developer.android.com/guide/topics/manifest/application-element#debug)) set to `true` in the AndroidManifest.xml. If this flag is set, an attacker can attach a debugger, and e.g., read and modify internals of the application.
+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.
 
-Having this flag set to `true` [is not considered a vulnerability](https://developer.android.com/privacy-and-security/risks/android-debuggable), however, it allow attackers to have more access to the app and resources than intended.
-
-!!! note Other ways to debug the application
-    Not enabling debugging in the AndroidManifest.xml does fully prevent all possibilities to debug the app. See @MASWE-0101 for more details on how to prevent debugging.
+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. View the AndroidManifest.xml using @MASTG-TECH-0117.
-2. Search the output for the debuggable flag (e.g. `android:debuggable` if using @MASTG-TOOL-0011 or `application-debuggable` if using @MASTG-TOOL-0124).
+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 contain the value of the debuggable flag from the AndroidManifest.xml or be empty.
+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 set to `true`.
+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

@@ -8,14 +8,9 @@ weakness: MASWE-0067
 
 ## Overview
 
-To enable debugging of Webviews, the API `WebView.setWebContentsDebuggingEnabled(true);` can be used to enable WebView debugging (see the ["Android documentation"](https://developer.chrome.com/docs/devtools/remote-debugging/webviews/#configure_webviews_for_debugging)).
+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.
 
-Calling this API will enable WebView debugging for **all** of the application's WebViews allowing an attached PC to eavesdrop on, and modify all communication inside WebViews.
-
-This flag works independently of the AndroidManifest.xml debuggable flag (see @MASTG-TEST-0226), so even if the app is not debuggable, the WebViews can be debuggable.
-
-!!! note Other ways to debug the application
-    Disabling WebView debugging does not fully prevent all possibilities to debug the app and the WebViews. See @MASWE-0101 for more details on how to prevent debugging.
+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
 
@@ -25,19 +20,34 @@ This flag works independently of the AndroidManifest.xml debuggable flag (see @M
 
 ## Observation
 
-The output should contain all locations where `WebView.setWebContentsDebuggingEnabled` can be called with `true` at runtime as well as any uses of `ApplicationInfo.FLAG_DEBUGGABLE`.
+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 there are any instances of WebView debugging being enabled and they can be always executed at runtime (meaning that the app does not check for the `ApplicationInfo.FLAG_DEBUGGABLE`).
+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:
 
-To mitigate this issue you can set the `WebView.setWebContentsDebuggingEnabled` calls to `false` or completely remove them altogether.
+- 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).
 
-If you want to enable WebView debugging only when debuggable is `true`, Android recommends [checking the 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.