Skip to content

Commit bc93250

Browse files
titzecpholguera
titze
and
cpholguera
authored
Port MASTG test 0019 (by @Guardsquare) (#3030)
* Port MASTG test 0019 * Fix markdown * Review feedback * Add Frida to trace traffic * Apply suggestions from code review * Refine MASTG-TEST-0x19-1.md for clarity on hardcoded HTTP URLs and their usage * Update covered_by references in MASTG-TEST-0019.md to reflect new test cases * Rename MASTG-TEST-0x19 test cases to MASTG-TEST-0233 through MASTG-TEST-0239 * update IDs * Update MASTG-TEST-0233 to modify title, improve evaluation and add related test references * Update MASTG-TEST-0239 note to clarify potential support for multiple weaknesses * Add --- at end of files for MASTG-TEST-0237, MASTG-TEST-0238, and MASTG-TEST-0239 * rm bare URL --------- Co-authored-by: Carlos Holguera <[email protected]>
1 parent bf03708 commit bc93250

File tree

8 files changed

+175
-0
lines changed

8 files changed

+175
-0
lines changed

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

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
---
2+
title: Hardcoded HTTP URLs
3+
platform: android
4+
id: MASTG-TEST-0233
5+
type: [static]
6+
weakness: MASWE-0050
7+
related-tests: [MASTG-TEST-0235, MASTG-TEST-0236, MASTG-TEST-0238]
8+
---
9+
10+
## Overview
11+
12+
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.
13+
14+
!!! warning Limitations
15+
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.
16+
17+
## Steps
18+
19+
1. Reverse engineer the app (@MASTG-TECH-0017).
20+
2. Run a static analysis (@MASTG-TECH-0014) tool and look for any `http://` URLs.
21+
22+
## Observation
23+
24+
The output contains a list of URLs and their locations within the app.
25+
26+
## Evaluation
27+
28+
The test case fails if any HTTP URLs are confirmed to be used for communication.
29+
30+
The presence of hardcoded HTTP URLs does not inherently mean they are used; their actual usage must be validated through careful inspection and testing:
31+
32+
- **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`.
33+
- **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.
34+
35+
Additionally, complement this static inspection with dynamic testing methods:
36+
37+
- **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.
38+
39+
- **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‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
title: SSLSockets not Properly Verifying Hostnames
3+
platform: android
4+
id: MASTG-TEST-0234
5+
type: [static]
6+
weakness: MASWE-0052
7+
---
8+
9+
## Overview
10+
11+
`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.
12+
13+
## Steps
14+
15+
1. Reverse engineer the app (@MASTG-TECH-0017).
16+
2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.
17+
18+
## Observation
19+
20+
The output contains a list of locations where `SSLSocket` and `HostnameVerifier` are used.
21+
22+
## Evaluation
23+
24+
The test case fails if hostname verification is missing or implemented incorrectly.

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

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
---
2+
title: Android App Configurations Allowing Cleartext Traffic
3+
platform: android
4+
id: MASTG-TEST-0235
5+
type: [static]
6+
weakness: MASWE-0050
7+
---
8+
9+
## Overview
10+
11+
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:
12+
13+
- **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.
14+
- **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.
15+
16+
## Steps
17+
18+
1. Reverse engineer the app (@MASTG-TECH-0017).
19+
2. Obtain the AndroidManifest.xml.
20+
3. Obtain the Network Security Configuration.
21+
4. Read the value of `usesCleartextTraffic` from the AndroidManifest.xml.
22+
5. Read the value of `cleartextTrafficPermitted` from the NSC `<base-config>` element.
23+
6. Read the value of `cleartextTrafficPermitted` from the NSC `<domain-config>` elements.
24+
25+
## Observation
26+
27+
The output contains a list of configurations potentially allowing for cleartext traffic.
28+
29+
## Evaluation
30+
31+
The test case fails if cleartext traffic is permitted. This can happen if any of the following is true:
32+
33+
1. The AndroidManifest sets `usesCleartextTraffic` to `true` and there's no NSC.
34+
2. The NSC sets `cleartextTrafficPermitted` to `true` in the `<base-config>`.
35+
3. The NSC sets `cleartextTrafficPermitted` to `true` in any `<domain-config>`.
36+
37+
**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:
38+
39+
```xml
40+
<?xml version="1.0" encoding="utf-8"?>
41+
<network-security-config>
42+
</network-security-config>
43+
```

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

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
---
2+
title: Cleartext Traffic Observed on the Network
3+
platform: network
4+
id: MASTG-TEST-0236
5+
type: [dynamic]
6+
weakness: MASWE-0050
7+
---
8+
9+
## Overview
10+
11+
This test intercepts the app's incoming and outgoing network traffic, and checks for any cleartext communication.
12+
Whilst the static checks can only show _potential_ cleartext traffic, this dynamic test shows all communication the application definitely makes.
13+
14+
!!! warning Limitation
15+
- 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.
16+
- Linking the intercepted traffic back to specific locations in the app can be difficult and requires manual analysis of the code.
17+
- 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.
18+
19+
## Steps
20+
21+
You can use one of the following approaches:
22+
23+
- Set up @MASTG-TECH-0010 (for Android) or @MASTG-TECH-0062 (for iOS) to capture all traffic.
24+
- Set up @MASTG-TECH-0011 (for Android) or @MASTG-TECH-0063 (for iOS) to capture all traffic.
25+
26+
**Notes**:
27+
28+
- 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.
29+
- 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)
30+
31+
## Observation
32+
33+
The output contains the captured network traffic.
34+
35+
## Evaluation
36+
37+
The test case fails if any clear text traffic originates from the target app.
38+
39+
**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‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
title: Cross-Platform Framework Configurations Allowing Cleartext Traffic
3+
platform: android
4+
id: MASTG-TEST-0237
5+
type: [static]
6+
weakness: MASWE-0050
7+
status: draft
8+
note: Cross-platform frameworks (e.g. Flutter, React native, ...), typically have their own implementations for HTTP libraries, where cleartext traffic can be allowed.
9+
---

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

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
title: Runtime Use of Network APIs Transmitting Cleartext Traffic
3+
platform: android
4+
id: MASTG-TEST-0238
5+
type: [dynamic]
6+
weakness: MASWE-0050
7+
status: draft
8+
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.
9+
---

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

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
title: Using low-level APIs (e.g. Socket) to set up a custom HTTP connection
3+
platform: android
4+
id: MASTG-TEST-0239
5+
type: [static]
6+
weakness: MASWE-0050
7+
status: draft
8+
note: This test could also be for MASWE-0049 but we'd need to support multiple weaknesses.
9+
---

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

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,9 @@ title: Testing Data Encryption on the Network
88
masvs_v1_levels:
99
- L1
1010
- L2
11+
status: deprecated
12+
covered_by: [MASTG-TEST-0233, MASTG-TEST-0234, MASTG-TEST-0235, MASTG-TEST-0236, MASTG-TEST-0237, MASTG-TEST-0238, MASTG-TEST-0239]
13+
deprecation_note: New version available in MASTG V2
1114
---
1215

1316
## Overview

0 commit comments

Comments
 (0)