refactor resilience best practices (#3092)

best-practices/MASTG-BEST-0007.md

@@ -0,0 +1,10 @@
+---
+title: Debuggable Flag Disabled in the AndroidManifest
+alias: debuggable-flag-disabled
+id: MASTG-BEST-0007
+platform: android
+---
+
+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.

best-practices/MASTG-BEST-0008.md

@@ -0,0 +1,29 @@
+---
+title: Debugging Disabled for WebViews
+alias: debugging-disabled-webviews
+id: MASTG-BEST-0008
+platform: android
+---
+
+Ensure that WebView debugging is disabled in production builds to prevent attackers from exploiting this feature to eavesdrop, modify, or debug communication within WebViews.
+
+- 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-beta/android/MASVS-RESILIENCE/MASTG-TEST-0226.md

@@ -4,6 +4,7 @@ platform: android
 id: MASTG-TEST-0226
 type: [static]
 weakness: MASWE-0067
+best-practices: [MASTG-BEST-0007]
 ---
 
 ## Overview
@@ -26,7 +27,3 @@ The output should explicitly show whether the `debuggable` flag is set (`true` o
 ## 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

@@ -4,6 +4,7 @@ platform: android
 id: MASTG-TEST-0227
 type: [static]
 weakness: MASWE-0067
+best-practices: [MASTG-BEST-0008]
 ---
 
 ## Overview
@@ -28,26 +29,3 @@ The output should list:
 ## 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.