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

weaknesses/MASVS-NETWORK/MASWE-0047.md

@@ -22,3 +22,30 @@ status: draft
 
 ---
 
+## Overview
+
+Certificate pinning is a security technique used to ensure that an app only trusts specific certificates or public keys when establishing secure connections. Insecure identity pinning occurs when the implementation of certificate or public key pinning is flawed or improperly configured. This weakness can leave the app vulnerable to Man-in-the-Middle (MITM) attacks and other security threats. Common issues include outdated pins, improper validation, accepting all certificates, or using insecure methods for dynamic pinning.
+
+## 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.
+- **Pinning to Insecure Certificates**: Pinning to self-signed, expired, or untrusted certificates that can be exploited.
+- **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

@@ -12,6 +12,33 @@ draft:
   description: e.g. FTP, SMTP, etc.
   topics: null
 status: draft
-
+note: move to cleartext traffic as a mode/test and repurpose for https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine ? 
 ---
 
+## Overview
+
+Applications that transmit data using insecure non-HTTP protocols that don't use TLS such as FTP, SMTP, or unencrypted TCP sockets are vulnerable to interception, eavesdropping, and manipulation by attackers. These protocols lack built-in encryption and authentication mechanisms, allowing sensitive information to be exposed during transmission. Without proper security measures, data sent over these channels can be easily accessed by unauthorized parties.
+
+## Impact
+
+- **Data Interception**: Attackers can capture and read unencrypted data transmitted over insecure protocols.
+- **Data Manipulation**: Unauthorized parties may alter data in transit, leading to corruption or injection of malicious content.
+- **Unauthorized Access**: Credentials or authentication tokens sent over insecure channels can be intercepted, enabling attackers to gain unauthorized access to systems or user accounts.
+- **Privacy Breach**: Exposure of personal or confidential information can lead to privacy violations and legal repercussions.
+- **Regulatory Non-Compliance**: Transmitting sensitive data without adequate protection may violate industry regulations and standards.
+
+## Modes of Introduction
+
+- **Use of Insecure Protocols**: Employing protocols like FTP, SMTP without TLS, or unsecured TCP sockets for data transmission.
+- **Legacy Systems Integration**: Integrating with older systems or services that only support insecure protocols.
+- **Custom Protocol Implementations**: Developing custom communication protocols without proper encryption and authentication.
+- **Misconfigured Secure Protocols**: Incorrectly configuring protocols intended to be secure, resulting in unencrypted communication (e.g., failing to enable TLS on SMTP servers).
+- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods.
+
+## Mitigations
+
+- **Use Secure Protocols**: Replace insecure protocols with secure alternatives that provide encryption and authentication, such as FTPS, SFTP or SMTPS.
+- **Implement Encryption**: If using custom protocols, ensure that data is encrypted in transit using standard encryption algorithms like TLS.
+- **Enable Protocol Security Features**: Configure protocols to use their built-in security features, such as enabling TLS for SMTP or FTP.
+- **Update Legacy Systems**: Work with legacy system providers to upgrade or replace systems to support secure communication protocols.
+- **Validate Third-Party Components**: Ensure that all third-party libraries and SDKs are configured to use secure communication methods by default.

weaknesses/MASVS-NETWORK/MASWE-0049.md

@@ -21,3 +21,29 @@ 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,60 @@ 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
 
-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
-
+status: new
 ---
 
+## 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 Globally in Configurations:** Global configuration settings allow cleartext traffic, making all network communication insecure.
+- **Per-Domain Exceptions for Cleartext Traffic:** Specific domains are allowed to use cleartext traffic, bypassing the secure communication requirements.
+- **Usage of Insecure Protocols:** Using insecure protocols such as HTTP or FTP which do not encrypt data in transit.
+- **Low-Level API Usage:** Use of low-level networking APIs that do not enforce encryption can inadvertently lead to the transmission of unprotected data.
+- **Cross-Platform Framework Misconfiguration:** Improper settings in cross-platform frameworks may allow cleartext traffic for both Android and iOS versions of an app.
+
+## Mitigations
+
+- **Use Secure Protocols:** Always use secure protocols like HTTPS, which employs TLS for encryption, 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.
+- **High-Level Network APIs:** Use high-level networking 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 networking 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.
+- **Implement Certificate Pinning**: Use certificate pinning with servers you control as an additional layer of security to prevent MITM attacks. Ensure proper implementation to handle certificate updates smoothly, and be cautious to avoid connectivity issues if certificates change. Avoid pinning certificates for third-party services unless you have control over their certificate management.

weaknesses/MASVS-NETWORK/MASWE-0051.md

@@ -19,3 +19,31 @@ 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.
+- **Validate and Sanitize Inputs**: Properly validate all incoming data from network connections to prevent injection attacks and buffer overflows.
+- **Use Secure Communication Protocols**: Employ encryption and secure protocols (e.g., TLS/SSL) for any network communication to protect data in transit.
+- **Configure Firewalls Appropriately**: Set up firewall rules to restrict access to open ports, allowing connections only from trusted sources.