Port MASTG test 0019 (by @guardsquare)

[titze]

This PR closes #2959.

Adds new draft tests:

• Using low-level APIs (e.g. Socket) to set up a custom HTTP connection.
• Cleartext traffic is allowed for cross-platform frameworks
• Runtime Use of Network APIs Transmitting Cleartext Traffic (Frida)

[cpholguera]

Wouldn't https://mas.owasp.org/MASWE/MASVS-NETWORK/MASWE-0052/ be a better fit?

[cpholguera]

After changing the above, we should update the steps and be more specific. We can tell them to search for uses of SSLSocket that are not using HostnameVerifier, or that are using it but potentially incorrectly (as indicated above).

Examples (not for linking here, but maybe to use later for demos):

• https://semgrep.dev/r?q=problem-based-packs.insecure-transport.java-spring.bypass-tls-verification.bypass-tls-verification
• https://semgrep.dev/playground/r/java.lang.security.audit.crypto.ssl.insecure-hostname-verifier.insecure-hostname-verifier?editorMode=advanced

[cpholguera]

Suggested change

	- Configuring the Network Security Configuration to enable cleartext traffic by setting the `cleartextTrafficPermitted` attribute to true on `<domain-config>` elements.
	- Configuring the [Network Security Configuration to enable cleartext traffic](https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted) by setting the `cleartextTrafficPermitted` attribute to true on `<domain-config>` elements.

[cpholguera]

Suggested change

	3. Inspect the AndroidManifest.xml, and check if a `networkSecurityConfig` is set in the `<application>` tag. If yes, inspect the referenced file, and make sure `cleartextTrafficPermitted` is not set to `true` for any domain.
	3. Inspect the AndroidManifest.xml, and check if a `networkSecurityConfig` is set in the `<application>` tag. If yes, inspect the referenced file, and make sure that `cleartextTrafficPermitted` is not set to `true`
	- globally in the `<base-config>` element.
	- or for specific domains in their `<domain-config>` elements.

[cpholguera]

More accurate like this I think.

Suggested change

	The output contains a list of domains for which cleartext traffic is enabled.
	The output contains a list of configurations allowing for cleartext traffic.

[cpholguera]

We can do this as long as there's a new Issue. Please mention the issue in the PR description.

Suggested change

	weakness: MASWE-0050
	---
	## Overview
	Cross-platform frameworks (e.g. Flutter, React native, ...), typically have their own implementations for HTTP libraries, where cleartext traffic can be allowed.
	## Steps
	## Observation
	## Evaluation
	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.
	---

[cpholguera]

Rephrase to highlight more why we're doing this test, what's the value/benefit. For example, this are REAL cleartext connections not just potential ones (as it is the case if we just retrieve the hardcoded URLs).

Limitations:

• thanks to doing this we can know what domains are contacted in cleartext but we don't know which location in the code is producing this traffic, right? (we can add a note in the Evaluation)
• this depends on how much of the app you can exercise so you cannot expect full coverage

[cpholguera]

See my new comment above, in the evaluation we can now use the output and explain how to discard false positives. This is not an easy task, but there are some things we can do to get a better list.