Port MASTG test 0019 (by @guardsquare)

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0233.md

@@ -0,0 +1,39 @@
+---
+title: Hardcoded HTTP URLs
+platform: android
+id: MASTG-TEST-0233
+type: [static]
+weakness: MASWE-0050
+related-tests: [MASTG-TEST-0235, MASTG-TEST-0236, MASTG-TEST-0238]
+---
+
+## Overview
+
+An Android app may have hardcoded HTTP URLs embedded in the app binary, library binaries, or other resources within the APK. These URLs may indicate potential locations where the app communicates with servers over an unencrypted connection.
+
+!!! warning Limitations
+    The presence of HTTP URLs alone does not necessarily mean they are actively used for communication. Their usage may depend on runtime conditions, such as how the URLs are invoked and whether cleartext traffic is allowed in the app's configuration. For example, HTTP requests may fail if cleartext traffic is disabled in the AndroidManifest.xml or restricted by the Network Security Configuration. See @MASTG-TEST-0235.
+
+## Steps
+
+1. Reverse engineer the app (@MASTG-TECH-0017).
+2. Run a static analysis (@MASTG-TECH-0014) tool and look for any `http://` URLs.
+
+## Observation
+
+The output contains a list of URLs and their locations within the app.
+
+## Evaluation
+
+The test case fails if any HTTP URLs are confirmed to be used for communication.
+
+The presence of hardcoded HTTP URLs does not inherently mean they are used; their actual usage must be validated through careful inspection and testing:
+
+- **Reverse Engineering**: Inspect the code locations where the HTTP URLs are referenced. Determine if they are merely stored as constants or actively used to create HTTP requests through networking APIs like `HttpURLConnection` or `OkHttp`.
+- **Static Analysis**: Analyze the app's configuration to identify whether cleartext traffic is permitted. For example, check the AndroidManifest.xml for `android:usesCleartextTraffic="true"` or inspect the `network_security_config`. Refer to @MASTG-TEST-0235 for detailed guidance.
+
+Additionally, complement this static inspection with dynamic testing methods:
+
+- **Dynamic Analysis**: Use tools like Frida to hook into networking APIs at runtime. This can reveal how and when the HTTP URLs are used during execution. See @MASTG-TEST-0238 for more details.
+
+- **Network Traffic Interception**: Capture and analyze network traffic using tools like Burp Suite, mitmproxy, or Wireshark. This approach confirms whether the app connects to the identified HTTP URLs during real-world usage but depends on the tester's ability to exercise the app's functionality comprehensively. See @MASTG-TEST-0236.

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0234.md

@@ -0,0 +1,24 @@
+---
+title: SSLSockets not Properly Verifying Hostnames
+platform: android
+id: MASTG-TEST-0234
+type: [static]
+weakness: MASWE-0052
+---
+
+## Overview
+
+`SSLSocket` does not perform hostname verification by default unless the app explicitly uses [`HostnameVerifier.verify()`](https://developer.android.com/reference/javax/net/ssl/HostnameVerifier#verify(java.lang.String,%20javax.net.SSL.SSLSession)). See the ["Android documentation"](https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket) and ["Unsafe HostnameVerifier"](https://developer.android.com/privacy-and-security/risks/unsafe-hostname) for more details.
+
+## Steps
+
+1. Reverse engineer the app (@MASTG-TECH-0017).
+2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.
+
+## Observation
+
+The output contains a list of locations where `SSLSocket` and `HostnameVerifier` are used.
+
+## Evaluation
+
+The test case fails if hostname verification is missing or implemented incorrectly.

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0235.md

@@ -0,0 +1,43 @@
+---
+title: Android App Configurations Allowing Cleartext Traffic
+platform: android
+id: MASTG-TEST-0235
+type: [static]
+weakness: MASWE-0050
+---
+
+## Overview
+
+Since Android 9 (API level 28) cleartext HTTP traffic is blocked by default (thanks to the [default Network Security Configuration](../../../Document/0x05g-Testing-Network-Communication.md#default-configurations)) but there are multiple ways in which an application can still send it:
+
+- **AndroidManifest.xml**: Setting the [`android:usesCleartextTraffic`](https://developer.android.com/guide/topics/manifest/application-element#usesCleartextTraffic) attribute of the `<application>` tag. Note that this flag is ignored in case the Network Security Configuration is configured.
+- **Network Security Configuration**: Setting the [`cleartextTrafficPermitted`](https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted) attribute to `true` on `<base-config>` or `<domain-config>` elements.
+
+## Steps
+
+1. Reverse engineer the app (@MASTG-TECH-0017).
+2. Obtain the AndroidManifest.xml.
+3. Obtain the Network Security Configuration.
+4. Read the value of `usesCleartextTraffic` from the AndroidManifest.xml.
+5. Read the value of `cleartextTrafficPermitted` from the NSC `<base-config>` element.
+6. Read the value of `cleartextTrafficPermitted` from the NSC `<domain-config>` elements.
+
+## Observation
+
+The output contains a list of configurations potentially allowing for cleartext traffic.
+
+## Evaluation
+
+The test case fails if cleartext traffic is permitted. This can happen if any of the following is true:
+
+1. The AndroidManifest sets `usesCleartextTraffic` to `true` and there's no NSC.
+2. The NSC sets `cleartextTrafficPermitted` to `true` in the `<base-config>`.
+3. The NSC sets `cleartextTrafficPermitted` to `true` in any `<domain-config>`.
+
+**Note:** The test doesn't fail if the AndroidManifest sets `usesCleartextTraffic` to `true` and there's a NSC, even if it only has an empty `<network-security-config>` element. For example:
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+<network-security-config>
+</network-security-config>
+```

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0236.md

@@ -0,0 +1,39 @@
+---
+title: Cleartext Traffic Observed on the Network
+platform: network
+id: MASTG-TEST-0236
+type: [dynamic]
+weakness: MASWE-0050
+---
+
+## Overview
+
+This test intercepts the app's incoming and outgoing network traffic, and checks for any cleartext communication.
+Whilst the static checks can only show _potential_ cleartext traffic, this dynamic test shows all communication the application definitely makes.
+
+!!! warning Limitation
+    - Intercepting traffic on a network level will show all traffic _the device_ performs, not only the single app. Linking the traffic back to a specific app can be difficult, especially when more apps are installed on the device.
+    - Linking the intercepted traffic back to specific locations in the app can be difficult and requires manual analysis of the code.
+    - Dynamic analysis works best when you interact extensively with the app. But even then there could be corner cases which are difficult or impossible to execute on every device. The results from this test therefore are likely not exhaustive.
+
+## Steps
+
+You can use one of the following approaches:
+
+- Set up @MASTG-TECH-0010 (for Android) or @MASTG-TECH-0062 (for iOS) to capture all traffic.
+- Set up @MASTG-TECH-0011 (for Android) or @MASTG-TECH-0063 (for iOS) to capture all traffic.
+
+**Notes**:
+
+- Interception proxies will show HTTP(S) traffic only. You can, however, use some tool-specific plugins such as [Burp-non-HTTP-Extension](https://github.com/summitt/Burp-Non-HTTP-Extension) or other tools like @MASTG-TOOL-0078 to decode and visualize communication via XMPP and other protocols.
+- Some apps may not function correctly with proxies like Burp and OWASP ZAP because of certificate pinning. In such a scenario, you can still use basic network sniffing to detect cleartext traffic. Otherwise, you can try to disable pinning (see @MASTG-TECH-0012 for Android and @MASTG-TECH-0064 for iOS)
+
+## Observation
+
+The output contains the captured network traffic.
+
+## Evaluation
+
+The test case fails if any clear text traffic originates from the target app.
+
+**Note**: This can be challenging to determine because traffic can potentially come from any app on the device. See the [Overview](#overview) section.

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0237.md

@@ -0,0 +1,9 @@
+---
+title: Cross-Platform Framework Configurations Allowing Cleartext Traffic
+platform: android
+id: MASTG-TEST-0237
+type: [static]
+weakness: MASWE-0050
+status: draft
+note: Cross-platform frameworks (e.g. Flutter, React native, ...), typically have their own implementations for HTTP libraries, where cleartext traffic can be allowed.
+---

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0238.md

@@ -0,0 +1,9 @@
+---
+title: Runtime Use of Network APIs Transmitting Cleartext Traffic
+platform: android
+id: MASTG-TEST-0238
+type: [dynamic]
+weakness: MASWE-0050
+status: draft
+note: Using Frida, you can trace all traffic of the app, mitigating the limitation of the dynamic analysis that you do not know which app, or which location is responsible for the traffic. Using Frida (and `.backtrace()`), you can be sure this is from the analyzed app, and know the exact location. A new limitation is then that all relevant networking APIs need to be instrumented.
+---

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0239.md

@@ -0,0 +1,9 @@
+---
+title: Using low-level APIs (e.g. Socket) to set up a custom HTTP connection
+platform: android
+id: MASTG-TEST-0239
+type: [static]
+weakness: MASWE-0050
+status: draft
+note: This test could also be for MASWE-0049 but we'd need to support multiple weaknesses.
+---

tests/android/MASVS-NETWORK/MASTG-TEST-0019.md

@@ -8,6 +8,9 @@ title: Testing Data Encryption on the Network
 masvs_v1_levels:
 - L1
 - L2
+status: deprecated
+covered_by: [MASTG-TEST-0233, MASTG-TEST-0234, MASTG-TEST-0235, MASTG-TEST-0236, MASTG-TEST-0237, MASTG-TEST-0238, MASTG-TEST-0239]
+deprecation_note: New version available in MASTG V2
 ---
 
 ## Overview