MASVS-NETWORK Refactoring (till 31.12.21)

[sushi2k]

Hello everybody,

as part of the refactoring process we decided to publish our draft of every section of the MASVS that we (@cpholguera @TheDauntless and myself) worked on.

This is based on the MASVS category "V5: Network Communication Requirements" (MASVS Version 1.3) MASVS: https://github.com/OWASP/owasp-masvs/blob/v1.3/Document/0x10-V5-Network_communication_requirements.md

Please let us know your feedback and thoughts on the Network communication requirements. Below you can find the summary of the original version, the refactoring and the proposed new requirements.

Original version

#	MSTG-ID	Description	L1	L2
5.1	MSTG-NETWORK-1	Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.	x	x
5.2	MSTG-NETWORK-2	The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards.	x	x
5.3	MSTG-NETWORK-3	The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.	x	x
5.4	MSTG-NETWORK-4	The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.		x
5.5	MSTG-NETWORK-5	The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.		x
5.6	MSTG-NETWORK-6	The app only depends on up-to-date connectivity and security libraries.		x

Refactoring

Note:

• Column "Status" can either be:
  • "New", for a completely new requirement
  • "Reworded" when changing an existing requirement
  • "Keep", when an existing requirement remains as is
  • "Removed" when removing an existing requirement.
• Column "Comment" contains a detailed explanation and reasoning for the change
• Column "Proposal" contains the proposed requirement for MASVS v.2.0

#	MSTG-ID	Description	L1	L2	Status	Comment	Proposal
5.1	MSTG-NETWORK-1	Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.	x	x	Reworded	- Why: Simplified requirement and removed "The secure channel is used consistently throughout the app.". Splitted the requirement into HTTP and non-HTTP; HTTP is using Burp and typical MITM attack - Test Case: (1) Setup MITM (2) Verify if HTTP is being used and (3)intercept HTTP(S)	All HTTP requests in transit between the app and endpoints are encrypted.
5.x	MSTG-NETWORK-X	All Non-HTTP requests in transit between the app and endpoints are encrypted.	x	x	New	- Why: see 5.1. Splitted the requirement into HTTP and non-HTTP; non-HTTP is Wireshark/tcpdump, different ways of becoming MITM (ARP / DNS Spoofing etc.) and using Burp extensions such as NoPE for a typical MITM attack. Simplified requirement and removed "The secure channel is used consistently throughout the app.". Test Case: (1) Setup MITM (2) Verify if Non-TLS communication is being used and (3) intercept Non-HTTP traffic
5.2	MSTG-NETWORK-2	The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards.	x	x	Reworded	- Why: "TLS Settings" renamed to "network security settings" so it covers all available network settings, such as DNS over HTTP (DoH), Certificate Transparency etc.; focuses only on client-side, not server-side! TLS settings on the server side are covered in ASVS "V9.2 Server Communications Security Requirements" and therefore is redundant for MASVS. - Test Case : Check TLS version, available cipher-suites etc and also (1) Check ATS - iOS (2) Check Network Security configuration - Android (3) Check that DNS over HTTP is activated, Certificate Transparency etc. https://developer.android.com/training/articles/security-config and https://developer.apple.com/documentation/security/preventing_insecure_network_connections;	The network security settings in the app are in line with current best practices.
5.3	MSTG-NETWORK-3	The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.	x	x	Reworded	- Why: We consider the case "app is not trusting user installed certificates" as part of 5.1. and limit the requirement to CA's available in system storage. - Test Case: Test case would be covering different scenarios for malicious CAs and certificates and how the app is handling and trusting them to execute a MITM attack (e.g. checks in TrustManager in Android might be overwritten)	The app verifies the X.509 certificate of the remote endpoint(s) when the secure channel is established. Only certificates signed by a trusted Certificate Authority (CA) that are part of the system storage (or "host platform"?) are accepted.
5.4	MSTG-NETWORK-4	The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.		x	Keep	This covers SSL Pinning, no change needed.
5.5	MSTG-NETWORK-5	The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.		x	Remove	Why: This is being done from server-side and covered in ASVS 2.5.6
5.6	MSTG-NETWORK-6	The app only depends on up-to-date connectivity and security libraries.		x	Remove	Why: It's covered by MSTG-CODE-5: All third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities.

Proposal

Note:

• As the requirements are referring to the MASVS and not MSTG, the ID nomenclature will be changed from "MSTG--ID" to "MASVS--ID".
• The MASVS-ID of existing requirements might be changing as part of the refactoring process.

#	MASVS-ID	Description	L1	L2
5.1	MASVS-NETWORK-1	All HTTP requests in transit between the app and endpoints are encrypted.	x	x
5.2	MASVS-NETWORK-2	All Non-HTTP requests in transit between the app and endpoints are encrypted.	x	x
5.3	MASVS-NETWORK-3	The network security settings in the app are in line with current best practices.	x	x
5.4	MASVS-NETWORK-4	The app verifies the X.509 certificate of the remote endpoint(s) when the secure channel is established. Only certificates signed by a trusted Certificate Authority (CA) that are part of the system storage (or "host platform"?) are accepted.	x	x
5.5	MASVS-NETWORK-5	The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.		x

Mapping between MASVS v1.3 to MASVS v2.0:

MSTG-ID (MASVS v1.3)	MASVS-ID (MASVS v2.0)	Status	Change of ID Number
MSTG-NETWORK-1	MASVS-NETWORK-1	Reworded	No
	MASVS-NETWORK-2	New
MSTG-NETWORK-2	MASVS-NETWORK-3	Reworded	Yes
MSTG-NETWORK-3	MASVS-NETWORK-4	Reworded	Yes
MSTG-NETWORK-4	MASVS-NETWORK-5	No change	Yes
MSTG-NETWORK-5		Removed
MSTG-NETWORK-6		Removed

[jmanico]

I would suggest dropping "/or as close as possible if the mobile operating system does not support the recommended standards/" that's kind of MEH for a standard. Don't give old crappy OS's a free pass! =) - Jim

[sushi2k]

Thanks for the feedback Jim!
Agree on this, the refactored requirement would be "The network security settings in the app are in line with current best practices.", short and sweet!

[julepka]

Just wanted to share my thought about

old 5.3: The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.

new 5.4: The app verifies the X.509 certificate of the remote endpoint(s) when the secure channel is established. Only certificates signed by a trusted Certificate Authority (CA) that are part of the system storage (or "host platform"?) are accepted.

New details look Android-specific. The current wording with fewer details allows abstracting from the platform. As I know, Apple deprecated and removed Objective-C methods that allowed customization of CA certificate checks several years ago. So, iOS is always good with this requirement just because of the system design. Additional details about certificates in the system storage may sound very confusing to iOS developers. Right now such details are mentioned in Android test cases and it seems to be more convenient. I'd suggest leaving 5.3 as-is and highlighting the part about certificates in system storage in Android test cases.

[TheDauntless]

As far as I know, Apple still allows you to do this? A recent example is here: https://developer.apple.com/forums/thread/666986 which appears to be working. Do you have any references on Apple removing the necessary APIs to disable certificate validation?

[julepka]

You are right, there is an API to allow self-signed certificates. Here is a doc how it works: https://developer.apple.com/documentation/foundation/url_loading_system/handling_an_authentication_challenge/performing_manual_server_trust_authentication

I haven't seen the API in a while. The requirement says "Only certificates signed by a trusted Certificate Authority..." and previously there was a method to check if it is signed by trusted CA (it was deprecated with no alternatives, but it may have changed since then). I mean, that the requirement sounds like if we have some custom logic for certificate acceptance, we must check if the certificate is signed by trusted CA (not just to avoid self-signed certificates). I think it confused me.

[cpholguera]

Consider: #576

tldr: keep it abstract and let the MSTG explain how to test (c.f. https://cwe.mitre.org/data/definitions/295.html)

[vixentael]

MSTG-NETWORK-5 | The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.

Are we sure that we want remove this requirement? I totally understand that it duplicates ASVS 2.5.6, and the plan is to make MASVS more specific to mobile. But hear me out :)

From my experience, many mobile applications don't have a solid backend, but rather a bunch of services working together instead (think Firebase and Twilio as SMS provider). Thus, developers never think about their backend as a proper backend -> never use ASVS.

On the other hand, account enrollment (aka user registration) is very common feature, available in most in mobile apps. This requirements covers it perfectly and emphasizes on secure user registration (and other account operations).

I suggest leaving this requirement without wording change as MSTG-NETWORK-6.

[cpholguera]

Hi @vixentael! I see your point, we'll discuss it. Thanks a lot for the feedback!

[cpholguera]

@vixentael, what about merging this with:

MSTG-AUTH-9: A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.
MSTG-AUTH-10: Sensitive transactions require step-up authentication.

In the MSTG we find:

https://mobile-security.gitbook.io/mobile-security-testing-guide/general-mobile-app-testing-guide/0x04f-testing-network-communication#making-sure-that-critical-operations-use-secure-communication-channels-mstg-network-5

https://mobile-security.gitbook.io/mobile-security-testing-guide/general-mobile-app-testing-guide/0x04e-testing-authentication-and-session-management#testing-two-factor-authentication-and-step-up-authentication-mstg-auth-9-and-mstg-auth-10

Any thoughts on this?

[cpholguera]

After analyzing all the feedback and giving some more thought to it we are re-releasing the proposal for the new MASVS-NETWORK requirements.

This time we include a better visualization as a diff spreadsheet including:

• Reason for removal/change.
• Idea behind the new requirement/formulation.
• More context thanks to related Test Cases.
• Filter in column F1 to see
  • the previous version only
  • the new version only
  • or the diff

MASVS-NETWORK is open for comments bis the end of December. Please comment directly in the Google Spreadsheet (you can comment on each of the cells) or in this GitHub Discussion.

MASVS-NETWORK Refactoring Diff

Thank you very much for all the feedback you sent over all different communication channels. Please keep that coming!

[cpholguera]

Current proposal (see all details and explanations in the Diff spreadsheed):

[julepka]

Just wanted to ask, will we have some time to update the translation after the OWASP team comes up with the final version?

And also, I think the list of links should be revisited. I see https://cwe.mitre.org/data/definitions/308.html in it that relates to single-factor auth. Its relation to Network requirements may not be straightforward. It may be better to keep the most relevant links there.

[cpholguera]

Closed for comments. Thanks everyone for your feedback so far!

[TheDauntless]

We might need to add a testcase about NOT implementing this yourself. This would be in line with AUTH, where there are different testcases for using a secure protocol and choosing an industry-standard implementation. Not sure under which control to put it yet, but the structure should be consistent between AUTH and NETWORKING (and maybe some others)

[cpholguera]

@TheDauntless I see a potential MASVS-CODE control here ("don’t roll your own xxx, instead use (high-level) platform provided APIs and services for sensitive transactions, security protocols, etc.). For example:

MASVS-CODE-7: The app uses platform provided implementations for security critical code, unless independently security vetted.

I see this useful for NETWORK, CRYPTO, AUTH, PLATFORM and some sensitive operations such as mobile in-app payments and we are already suggesting tests for this in different controls. The control might be in MASVS-CODE but we'll have many tests across other categories mapping back to it.

Relates to FPT_API_EXT.1 (NIAP).