M3: Inadequate Transport Layer Protection

Overview

This JSON response furnishes information about the vulnerability M3: Inadequate Transport Layer Protection. It elucidates the threat agents, attack vectors, security weakness, technical impacts, and business impacts. Additionally, it outlines measures to prevent this vulnerability and provides example attack scenarios.

Description

M3: Inadequate Transport Layer Protection is a vulnerability occurring when a mobile application neglects to sufficiently safeguard network traffic during data transmission. This can lead to the interception of sensitive data by threat agents, such as those on a compromised Wi-Fi network or malware on the mobile device. The absence of transport layer protection exposes users to the risk of data exposure, account theft, and potential phishing or MITM attacks. To counter this vulnerability, it is recommended to apply SSL/TLS to transport channels, employ robust cipher suites, and verify the authenticity of SSL certificates. Additionally, sensitive data should not be sent over alternate channels, and a secondary layer of encryption can be applied.

How to Prevent ?

To avert 'Inadequate Transport Layer Protection,' adhere to the following best practices: 1. Assume that the network layer is insecure and susceptible to eavesdropping. 2. Apply SSL/TLS to transport channels used by the mobile app to transmit sensitive information, session tokens, or other critical data to a backend API or web service. 3. Account for outside entities like third-party analytics companies, social networks, etc., using their SSL versions when an application runs a routine via the browser/webkit. 4. Employ strong, industry-standard cipher suites with appropriate key lengths. 5. Utilize certificates signed by a trusted CA provider. 6. Never permit self-signed certificates and consider certificate pinning for security-conscious applications. 7. Always require SSL chain verification. 8. Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain. 9. Alert users through the UI if the mobile app detects an invalid certificate. 10. Avoid sending sensitive data over alternate channels (e.g., SMS, MMS, or notifications). 11. If possible, apply a separate layer of encryption to any sensitive data before it is provided to the SSL channel.

Example Attack Scenarios:

• Absence of Certificate Inspection:  The mobile app and an endpoint successfully connect and perform an SSL/TLS handshake to establish a secure channel. However, the mobile app neglects to inspect the certificate offered by the server and unconditionally accepts any certificate offered. This compromises mutual authentication capability and makes the mobile app susceptible to man-in-the-middle attacks.

• Weak Handshake Negotiation:  The mobile app and an endpoint successfully connect and negotiate a weak cipher suite as part of the connection handshake. This results in weak encryption that can be easily decrypted by an adversary, jeopardizing the confidentiality of the channel.

• Privacy Information Leakage:  The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This exposes the confidentiality of any privacy-related data exchanged between the mobile app and the endpoint.