Align TESTs 242-244 with iOS (Pinning)

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

@@ -6,25 +6,41 @@ type: [static, code]
 weakness: MASWE-0047
 profiles: [L2]
 knowledge: [MASTG-KNOW-0014, MASTG-KNOW-0015]
+prerequisites:
+- identify-first-party-domains
 ---
 
 ## Overview
 
 Apps can configure [certificate pinning using the Network Security Configuration](../../../knowledge/android/MASVS-NETWORK/MASTG-KNOW-0015.md#pinning-via-network-security-configuration-api-24). For each domain, one or multiple digests can be pinned.
 
-The goal of this test is to check if the app does not implement certificate pinning using the NSC. However, note that the app may be using other pinning methods covered in other tests.
+This test checks whether the app configures certificate pinning in the NSC for the relevant first-party domains it connects to. Relevant domains are remote endpoints under the developer's control that support the app's core or security-sensitive functionality. Third-party domains outside the developer's control **should not be reported** as missing pins only because they appear in app traffic. Note that the app may implement certificate pinning through other mechanisms covered in other tests.
 
 ## Steps
 
 1. Use @MASTG-TECH-0013 to reverse engineer the app.
 2. Use @MASTG-TECH-0117 to obtain the AndroidManifest.xml
 3. Use @MASTG-TECH-0150 to check if a `networkSecurityConfig` is set in the `<application>` tag.
 4. Use @MASTG-TECH-0151 to extract all domains from `<domain-config>` that have a pin set (`<pin-set>`) from the Network Security Configuration file.
+5. Use @MASTG-TECH-0022 to identify the first-party domains the app connects to.
 
 ## Observation
 
-The output should contain a list of domains which enable certificate pinning.
+The output should contain a list of domains that enable certificate pinning. The output should also identify any relevant first-party domains that were found in the app but do not have a pin set.
 
 ## Evaluation
 
-The test case fails if no `networkSecurityConfig` is set, or any relevant domain does not enable certificate pinning.
+The test case fails if the app connects to relevant first-party domains but no `networkSecurityConfig` is set, or if `networkSecurityConfig` is set but does not enable certificate pinning for those domains.
+
+The test case should not fail only because unrelated third-party domains are not pinned.
+
+If another certificate pinning implementation is identified for the same domains, such as a custom `TrustManager` or a third-party library, the result should be treated as not covered by NSC pinning rather than as a confirmed absence of certificate pinning.
+
+**Further Validation Required:**
+
+Before reporting a missing pin, confirm that the app actually establishes connections to the relevant first-party domains:
+
+- Statically, follow the data references from the hardcoded URLs to the code that initiates the network connections (@MASTG-TECH-0023).
+- Dynamically, capture and analyze the network traffic (@MASTG-TECH-0011) or hook the relevant network APIs at runtime to log the domains the app connects to.
+
+Determining which domains are first-party and security-relevant typically requires information that is not present in the app binary and may require contact with the developers.

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

@@ -6,6 +6,8 @@ type: [static, code]
 weakness: MASWE-0047
 profiles: [L2]
 knowledge: [MASTG-KNOW-0014, MASTG-KNOW-0015]
+prerequisites:
+- identify-first-party-domains
 ---
 
 ## Overview
@@ -16,19 +18,31 @@ If developers assume pinning is still in effect but don't realize it has expired
 
 > Example: A financial app previously pinned to its own private CA but, after expiration, starts trusting publicly trusted CAs, increasing the risk of compromise if a CA is breached.
 
-The goal of this test is to check if any expiration date is in the past.
+This test checks whether any certificate pin configured for a relevant first-party domain has expired. Relevant domains are remote endpoints under the developer's control that support the app's core or security-sensitive functionality.
 
 ## Steps
 
 1. Use @MASTG-TECH-0013 to reverse engineer the app.
 2. Use @MASTG-TECH-0117 to obtain the AndroidManifest.xml.
 3. Use @MASTG-TECH-0150 to check if `android:networkSecurityConfig` is set in the `<application>` tag.
 4. Use @MASTG-TECH-0151 to extract the expiration dates for all certificate pins from the Network Security Configuration file.
+5. Use @MASTG-TECH-0022 to identify the first-party domains the app connects to.
 
 ## Observation
 
-The output should contain a list of expiration dates for pinned certificates.
+The output should contain a list of expiration dates for pinned certificates, along with the domains they apply to. The output should also identify which of those domains are relevant first-party domains the app connects to.
 
 ## Evaluation
 
-The test case fails if any expiration date is in the past.
+The test case fails if any certificate pin configured for a relevant first-party domain has an expiration date in the past.
+
+The test case should not fail only because pins for unrelated third-party domains have expired.
+
+**Further Validation Required:**
+
+Before reporting an expired pin, confirm that the app actually establishes connections to the affected first-party domains:
+
+- Statically, follow the data references from the hardcoded URLs to the code that initiates the network connections (@MASTG-TECH-0023).
+- Dynamically, capture and analyze the network traffic (@MASTG-TECH-0011) or hook the relevant network APIs at runtime to log the domains the app connects to.
+
+Determining which domains are first-party and security-relevant typically requires information that is not present in the app binary and may require contact with the developers.

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

@@ -6,6 +6,8 @@ type: [dynamic, network]
 weakness: MASWE-0047
 profiles: [L2]
 knowledge: [MASTG-KNOW-0015]
+prerequisites:
+- identify-first-party-domains
 ---
 
 ## Overview
@@ -16,6 +18,8 @@ The goal of this test case is to observe whether a [MITM attack](../../../Docume
 
 If the app is properly implementing certificate pinning, the MITM attack should fail because the app rejects certificates issued by an unauthorized CA, even if the CA is trusted by the system.
 
+This test focuses on relevant first-party domains, which are remote endpoints under the developer's control that support the app's core or security-sensitive functionality. Third-party domains outside the developer's control should not be reported only because their traffic can be intercepted.
+
 _Testing Tip:_ While performing the MITM attack, it can be useful to monitor the system logs (see @MASTG-TECH-0009). If a certificate pinning/validation check fails, an event similar to the following log entry might be visible, indicating that the app detected the MITM attack and did not establish a connection.
 
 `I/X509Util: Failed to validate the certificate chain, error: Pin verification failed`
@@ -27,8 +31,14 @@ _Testing Tip:_ While performing the MITM attack, it can be useful to monitor the
 
 ## Observation
 
-The output should contain the intercepted traffic capture.
+The output should contain the intercepted traffic capture, including the domains whose HTTPS traffic was successfully intercepted.
 
 ## Evaluation
 
-The test case fails if any relevant domain appears in the intercepted traffic capture.
+The test case fails if any relevant first-party domain appears in the intercepted traffic capture.
+
+The test case should not fail only because unrelated third-party domains are intercepted.
+
+**Further Validation Required:**
+
+Determining which of the intercepted domains are first-party and security-relevant typically requires information that is not present in the app binary and may require contact with the developers.