Add MASWE-0047, MASWE-0048, MASWE-0049, MASWE-0050, MASWE-0051, MASWE…

…-0052 (#2919)

* Add overview, impact, modes of introduction, and mitigations

* inital drafts

* Apply suggestions from code review

Co-authored-by: Jeroen Beckers <[email protected]>

* Apply suggestions from code review

Co-authored-by: Sven <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Jeroen Beckers <[email protected]>

* Update weaknesses/MASVS-NETWORK/MASWE-0047.md

* Update weaknesses/MASVS-NETWORK/MASWE-0047.md

* Refactor MASWE-0048: Update title and description for Insecure Machine-to-Machine Communication; remove content and enhance draft data

* Refactor MASWE-0047, MASWE-0049, MASWE-0051 and MASWE-0052: Remove draft sections and update status to new

* Refactor MASWE-0050: Update modes of introduction and mitigations for cleartext traffic; merge Platform-provided Settings (global and per-domain), incorporate non-http and remove pinning mitigation

* Apply suggestions from code review

* Update weaknesses/MASVS-NETWORK/MASWE-0051.md

---------

Co-authored-by: Jeroen Beckers <[email protected]>
Co-authored-by: Sven <[email protected]>
Co-authored-by: Copilot <[email protected]>

weaknesses/MASVS-NETWORK/MASWE-0047.md

@@ -7,18 +7,41 @@ profiles: [L2]
 mappings:
   masvs-v1: [MSTG-NETWORK-4]
   masvs-v2: [MASVS-NETWORK-2]
+status: new
+---
 
-draft:
-  description: e.g. via NSC/ATS, okhttp CertificatePinner, volley, trustkit, Cordova,
-    AFNetworking SSLPinningMode
-  topics:
-  - NSC/ATS
-  - net-frameworks e.g. okhttp CertificatePinner, volley, trustkit, Cordova, AFNetworking
-    SSLPinningMode
-  - Dynamic Pinning e.g. via the ssl-pinning-android library
-  - Check for MITM resiliency, e.g. with trusted interceptor cert. consider "proxy
-    unaware apps"
-status: draft
+## Overview
 
----
+[Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication/#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers.
+
+When a mobile app does not implement certificate pinning, or if it is implemented incorrectly, the app remains vulnerable to Machine-in-the-Middle (MITM) attacks which enable attackers to intercept and modify the communication between the app and the intended server. This occurs because when the app is presented a fraudulent certificate that the app may unknowingly trust, thereby gaining access to sensitive data or injecting malicious content into the data stream.
+
+**Limitations**: Certificate pinning adds a layer of trust verification by ensuring that the app only accepts connections to servers with specific, pre-determined certificates or public keys. This reduces the risk of unauthorized interception, even if a trusted Certificate Authority (CA) is compromised. However, it is not foolproof:
+
+- Attackers who can reverse-engineer the app may analyze and remove or modify the pre-defined pins or the certificate pinning logic to permanently bypass the checks.
+- Attackers who can perform @MASTG-TECH-0051 techniques to manipulate the app and bypass pinning checks.
+
+This highlights the importance of implementing certificate pinning **alongside other security measures** to enhance the app's resistance to advanced threats.
+
+## Impact
+
+- **Data Interception**: Sensitive data such as credentials, personal information, or financial details can be captured by unauthorized parties.
+- **Data Manipulation**: Attackers can not only intercept but also manipulate data if pinning is not properly enforced.
+- **Denial of Service**: Incorrect pinning may cause legitimate connections to fail, leading to service disruptions for users. For example, if a pinned certificate expires and is not updated, the app may be unable to establish secure connections.
+
+## Modes of Introduction
+
+- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning.
+- **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation, making it easy for attackers to supply malicious pins.
+- **Weak Validation Logic**: Custom pinning implementations that do not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key.
+- **Lack of Backup Pins**: Not including backup pins to prevent connectivity issues if the primary pin is no longer valid.
+
+## Mitigations
 
+- **Prefer Platform-provided Solutions**: Use platform-provided mechanisms like Android's Network Security Configuration (NSC) or iOS's App Transport Security (ATS) to enforce pinning.
+- **Use Trusted Pinning Libraries**: Refrain from writing custom pinning logic; instead, rely on established and well-maintained libraries and frameworks (e.g., TrustKit, OkHttp's `CertificatePinner`) and ensure they are correctly configured according to best practices.
+- **Secure Dynamic Pinning**: If dynamic pinning is necessary, retrieve pins over secure channels and validate them thoroughly before use.
+- **Pin to Public Keys Instead of Certificates**: Pin to the certificate's public key rather than the whole certificate to avoid issues regarding expiration and renewals.
+- **Consistent Enforcement**: Apply pinning uniformly for all connections to servers that you control.
+- **Regularly Update Pins**: Keep the pinned certificates or public keys up to date with the server's current configuration and have a process for updating the app when changes occur.
+- **Implement Backup Pins**: Include backup pins (hashes of additional trusted public keys) to prevent connectivity issues if the primary key changes.

weaknesses/MASVS-NETWORK/MASWE-0048.md

@@ -1,17 +1,21 @@
 ---
-title: Insecure Non-HTTP Traffic
+title: Insecure Machine-to-Machine Communication
 id: MASWE-0048
-alias: insecure-non-http
+alias: insecure-m2m
 platform: [android, ios]
 profiles: [L1, L2]
 mappings:
   masvs-v1: [MSTG-NETWORK-1]
   masvs-v2: [MASVS-NETWORK-1]
-
+  android-risks:
+    - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine
 draft:
-  description: e.g. FTP, SMTP, etc.
-  topics: null
+  description: Android applications often use technologies like Bluetooth, NFC, and USB for data transfer and device interaction. Developers must use these APIs carefully to prevent data exposure and remote device takeover by attackers.
+  topics:
+    - Bluetooth
+    - BLE
+    - NFC
+    - USB
+    - Wi-Fi P2P
 status: draft
-
 ---
-

weaknesses/MASVS-NETWORK/MASWE-0049.md

@@ -1,23 +1,38 @@
 ---
-title: Proved Networking APIs Not used
+title: Proven Networking APIs Not used
 id: MASWE-0049
-alias: no-proved-net-apis
+alias: no-proven-net-apis
 platform: [android, ios]
 profiles: [L2]
 mappings:
   masvs-v1: [MSTG-NETWORK-6]
   masvs-v2: [MASVS-NETWORK-1, MASVS-CODE-3]
+status: new
+---
 
-draft:
-  description: AKA don't roll your own network security. For example, platform-provided
-    authentication APIs or openssl are designed and implemented by experts who have
-    deep knowledge of the platform's security features and considerations. These APIs
-    often incorporate security best practices and are regularly updated to address
-    new threats and vulnerabilities.
-  topics:
-  - Platform-provided Networking APIs Not used
-  note: maybe merge with the next one or find a better separation
-status: draft
+## Overview
 
----
+Applications that do not utilize platform-provided networking APIs or well-established security libraries are susceptible to security vulnerabilities. When developers implement custom networking code or "roll-your-own" security mechanisms, they risk introducing flaws due to a lack of deep expertise in cryptography and network security. Platform-provided APIs and libraries, such as `NSURLSession` on iOS or `HttpsURLConnection` on Android, are designed and maintained by experts, incorporating security best practices and regular updates to address new threats and vulnerabilities.
+
+## Impact
+
+- **Security Vulnerabilities**: Custom networking implementations may contain flaws that attackers can exploit, leading to data breaches and unauthorized access.
+- **Lack of Updates**: Custom code may not receive timely updates to address new vulnerabilities or comply with evolving security standards.
+- **Inconsistent Security Measures**: Bypassing standard APIs can result in inconsistent application of security features like encryption, certificate validation, and error handling.
+- **Increased Development Complexity**: Writing and maintaining custom networking code increases complexity, making it harder to audit and secure the application.
+- **Non-Compliance with Standards**: Failing to use approved APIs may lead to non-compliance with industry regulations and security guidelines.
+
+## Modes of Introduction
+
+- **Custom Networking Stack Development**: Developers create their own networking code instead of using platform-provided APIs, possibly to add custom features or due to unfamiliarity with existing APIs.
+- **Use of Insecure Third-Party Libraries**: Incorporating third-party networking libraries that are outdated or do not follow current security best practices.
+- **Bypassing Security Mechanisms**: Deliberately avoiding standard APIs to circumvent security checks, such as certificate pinning or TLS enforcement.
+- **Insufficient Security Knowledge**: Developers may lack adequate understanding of network security principles, leading to insecure implementations.
+- **Performance Optimization Attempts**: Writing custom networking code to optimize performance without fully considering the security implications.
+
+## Mitigations
 
+- **Utilize Platform-Provided Networking APIs**: Always use the networking APIs provided by the platform, such as `NSURLSession` for iOS and `HttpsURLConnection` for Android, which handle many security concerns internally.
+- **Adopt Established Security Libraries**: If additional functionality is required, use reputable, well-maintained libraries like `OkHttp` for Android or `Alamofire` on iOS  that adhere to security best practices.
+- **Avoid Custom Security Implementations**: Refrain from implementing custom cryptographic algorithms or security protocols; rely on standard, vetted solutions instead.
+- **Keep Dependencies Updated**: Regularly update all libraries and dependencies to incorporate the latest security patches and improvements.

weaknesses/MASVS-NETWORK/MASWE-0050.md

@@ -8,28 +8,59 @@ mappings:
   masvs-v1: [MSTG-NETWORK-2]
   masvs-v2: [MASVS-NETWORK-1]
   cwe: [319]
+  android-risks:
+    - https://developer.android.com/privacy-and-security/risks/cleartext-communications
+  android-core-app-quality: [SC-9, SC-N1, SC-N2]
+refs:
+- https://developer.apple.com/documentation/security/preventing-insecure-network-connections
+- https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsexceptiondomains
+- https://developer.apple.com/documentation/network
+- https://developer.apple.com/documentation/foundation/urlsession
+- https://developer.android.com/privacy-and-security/security-best-practices#secure-communication
+- https://developer.android.com/privacy-and-security/security-tips#networking
+- https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted
+- https://developer.android.com/reference/javax/net/ssl/SSLSocket
+- https://developer.android.com/reference/android/security/NetworkSecurityPolicy#isCleartextTrafficPermitted()
+- https://developer.android.com/reference/java/net/Socket
+- https://developer.android.com/reference/android/webkit/WebView
+- https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection
+- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/android/app-fundamentals/http-stack.md
+- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/ios/app-fundamentals/ats.md
+status: new
+---
 
-draft:
-  description: The app sends or receives data over an insecure channel, such as HTTP,
-    FTP, or SMTP. This data can be intercepted and read by an attacker without needing
-    to perform Man-in-the-Middle attacks. The app should use HTTPS, SFTP, or SMTPS
-    instead.
-  topics:
-  - exceptions and if justifications are given using the platform provided mechanisms
-    (Secure by Default Configuration).
-  - Cleartext Traffic allowed in App Network Configuration (usesCleartextTraffic in
-    Android Manifest, cleartextTrafficPermitted in NSC, ATS allowInsecureLoads)
-  - cleartext in traffic capture
-  - Usage of HTTP traffic (e.g. HTTP URLs)
-  - cross-platform framework e.g. Flutter, Xamarin
-  - use of low-level APIs e.g. SSLSocket on Android or Network on iOS. ATS doesn't
-    apply there. Prefer high-level API calls such as Android HttpsURLConnection/iOS
-    URLSession.
-  - configs./ input params, logic e.g. on third-party or low-level frameworks such
-    as SSLSocket on Android or Network on iOS
-  - Watch Communications
-  - Peer-to-peer communications (e.g. WiFi-direct, Nearby)
-status: draft
+## Overview
 
----
+When data is sent in cleartext (i.e. without encryption) it becomes accessible to attackers who can monitor network channels. Attackers can perform passive eavesdropping to intercept data or employ active Machine-in-the-Middle (MITM) attacks to manipulate data, potentially altering app behavior or injecting malicious content.
+
+This weakness is especially concerning when sensitive information is transmitted without encryption, putting user privacy and security at direct risk. Even when sensitive data isn't being transmitted, using cleartext communication remains a vulnerability. Network attacks like ARP poisoning and DNS spoofing can allow attackers to intercept or redirect traffic, potentially disrupting app functionality or deceiving users by redirecting them to malicious sites that impersonate legitimate services.
+
+If the connections were secured using encryption and proper authentication mechanisms, these attacks would be much harder to perform because the attacker would need to bypass encryption and certificate validation. Secure network protocols not only provide confidentiality but also ensure data integrity and authenticity through encryption and certificate validation, preventing attackers from altering data.
+
+## Impact
+
+- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network.
+- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content.
+- **Unauthorized Access**: Attackers may intercept session tokens or credentials sent over cleartext channels, enabling them to impersonate users and gain unauthorized access to user accounts or systems.
+- **Privacy Breach**: Personal and confidential user information could be exposed, violating privacy regulations.
+- **Regulatory Compliance Violations**: Exposing sensitive data may lead to non-compliance with laws like GDPR or HIPAA, resulting in legal penalties.
+- **Reputation Damage**: Security breaches can erode user trust and harm the organization's reputation.
+
+## Modes of Introduction
+
+- **Cleartext Traffic Allowed in Platform-provided Settings:** Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings.
+- **Usage of HTTP:** Using HTTP instead of HTTPS for communication, which does not encrypt data in transit.
+- **Usage of Non-HTTP Insecure Protocols:** Using insecure protocols such as FTP, SMTP without TLS, TCP sockets or custom protocols which do not encrypt data in transit.
+- **Usage of Low-Level Network APIs:** Use of low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS.
+- **Cross-Platform Framework Misconfiguration:** Improper settings in cross-platform frameworks may allow cleartext traffic for both Android and iOS versions of an app.
+- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured.
+
+## Mitigations
 
+- **Use Secure Protocols:** Always use secure protocols like HTTPS (which employs TLS for encryption), FTPS, SFTP or SMTPS for all communication channels. Ensure these protocols are used consistently throughout the app.
+- **Explicitly Disable Cleartext Traffic:** Never allow cleartext traffic globally in the app configuration. Ensure that cleartext traffic is explicitly disabled using security settings like the Network Security Configuration on Android and App Transport Security (ATS) on iOS. Prefer per-domain exceptions over global settings but use them carefully and only when there is no other option.
+- **Use Per-Domain Exceptions Sparingly:** If cleartext traffic is absolutely necessary for specific domains, ensure these domains are trusted and essential for the app's functionality, and conduct a thorough risk assessment before including them.
+- **Prefer Server Fixes**: Whenever possible, work with the server team to enable secure communication. Instead of adding network security exceptions to the mobile app, such as allowing cleartext traffic or lowering the minimum TLS version, update server configurations to support HTTPS with valid certificates and modern TLS protocols.
+- **Use High-Level Network APIs:** Use high-level network APIs that automatically handle encryption, certificate validation, and errors, such as [`HttpsURLConnection`](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection) on Android or [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) on iOS. Avoid using low-level network APIs or custom network stacks that bypass the platform-provided network security features.
+- **Use Secure Cross-Platform Frameworks:** Ensure that cross-platform frameworks—such as React Native, Flutter, or Xamarin—are configured to enforce secure communication by default and do not allow cleartext traffic. Review the framework's documentation and adjust network security settings to align with best practices.
+- **Use Secure Third-Party Components**: Verify that any third-party libraries and SDKs used in the app enforce secure communication protocols, especially if they handle sensitive data or use low-level networking APIs. Ensure that these components are regularly updated to address any vulnerabilities.

weaknesses/MASVS-NETWORK/MASWE-0051.md

@@ -7,15 +7,32 @@ profiles: [L2]
 mappings:
   masvs-v1: [MSTG-NETWORK-2]
   masvs-v2: [MASVS-NETWORK-1]
+status: new
+---
 
-draft:
-  description: e.g. the app uses a server socket and binds to INADDR_ANY or uses a
-    loopback address. This allows other apps to connect to the app's server socket
-    and communicate with it.
-  topics:
-  - no loopback
-  - no binding to INADDR_ANY
-status: draft
+## Overview
 
----
+Applications that open network ports without proper protection are vulnerable to unauthorized access and potential exploitation. This weakness occurs when an application listens on a network port and accepts incoming connections without adequate security measures, allowing other applications or attackers to connect and interact with it.
+
+## Impact
+
+- **Unauthorized Access**: Attackers can connect to open ports and gain access to application functionalities or sensitive data.
+- **Data Leakage**: Sensitive information may be exposed through unprotected ports if proper authentication and encryption are not enforced.
+- **Remote Code Execution**: Exploitation of open ports can lead to the execution of arbitrary code on the device.
+- **Denial of Service**: Attackers may overload the open port, causing the application or device to become unresponsive.
+- **Privacy Breach**: User data and application state can be compromised, leading to privacy violations and non-compliance with regulations.
+
+## Modes of Introduction
+
+- **Binding to All Network Interfaces**: Configuring the application to bind to all available network interfaces (e.g., using wildcard addresses), making it accessible over untrusted networks.
+- **Insecure Loopback Address Usage**: Misconfiguring the application to listen on loopback addresses without proper access restrictions.
+- **Lack of Access Controls**: Failing to implement authentication and authorization mechanisms for services exposed via open ports.
+- **Debug Services Left Enabled**: Leaving development or debugging network services active in production releases.
+- **Misconfigured Firewall Settings**: Not setting up proper firewall rules, allowing unauthorized inbound connections to open ports.
+
+## Mitigations
 
+- **Restrict Network Bindings**: Configure the application to bind only to specific, necessary network interfaces, avoiding the use of wildcard addresses like `INADDR_ANY`.
+- **Implement Strong Access Controls**: Enforce authentication and authorization for any services exposed through open ports to ensure only authorized entities can connect.
+- **Disable Debugging Services in Production**: Ensure that all development and debugging network services are disabled or removed in production builds.
+- **Configure Firewalls Appropriately**: Set up firewall rules to restrict access to open ports, allowing connections only from trusted sources.