Understanding OWASP Top 10 Mobile: Insufficient Transport Layer Protection

Recent statistics show that almost half of the breaches that cause significant damage now occur through mobile applications. The Open Web Application Security Project (OWASP) has been categorizing, evangelizing, and publishing remediation information for web application security for 12 years. Over the last three years, OWASP has also started publishing a list of the Top 10 Mobile Threats.

Today, we will discuss in detail the third most prevalent mobile threat according to OWASP: Insufficient Transport Layer Protection.

What is Insufficient Transport Layer Protection?

Insufficient Transport Layer Protection happens when apps don’t properly secure the data they send over the internet. While apps might use SSL/TLS to protect information during login, they often forget to use it elsewhere, leaving sensitive data and session IDs exposed. This makes it easy for hackers to intercept and exploit the app.

OWASP points out that many apps don’t fully secure network traffic—they don’t always authenticate or encrypt data, and even when they do, they sometimes use weak encryption or outdated certificates.

Typically, when a mobile application is designed, data is exchanged in a client-server fashion. This data can traverse both a carrier network and the Internet.

If the application is coded poorly for sensitive data, threat agents can use techniques to view this sensitive data while it is in the mode of travel. Obviously, you would not want sensitive information like passwords, credit card numbers, or other sensitive data traveling without some encryption, generally HTTPS. To handle HTTPS correctly, you must also learn to code options around certificates in your mobile applications.

Unfortunately, mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing sensitive data to interception.

What are some ways to exploit Insufficient Transport Layer Protection?

The following threat agents exist:

• An adversary that shares your local network (compromised or monitored Wi-Fi)
• Carrier or network devices (routers, cell towers, proxy's, etc)
• Malware on your mobile device
• Hackers trying to attack you web services

Are you vulnerable to Insufficient Transport Layer Protection?

To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:

• Are all connections, not just ones to servers you own, properly encrypted?
• Are the SSL certificates in date?
• Are the SSL certificates self signed?
• Does the SSL use high enough cipher strengths?
• Will your application accept user accepted certificates as authorities?

How to prevent Insufficient Transport Layer Protection?

General best practices:

• Assume that the network layer is not secure and is susceptible to eavesdropping.
• Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
• Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.
• Use strong, industry standard cipher suites with appropriate key lengths.
• Use certificates signed by a trusted CA provider.
• Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
• Always require SSL chain verification.
• Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
• Alert users through the UI if the mobile app detects an invalid certificate.
• Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).

iOS specific best practices

Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:

• Ensure that certificates are valid and fail closed.
• When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
• After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
• Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

Android specific best practices

• Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOWALLHOSTNAME_VERIFIER. These are equivalent to trusting all certificates.
• If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.

Examples of Insufficient Transport Layer Protection

Lack of certificate inspection

The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a SSL proxy

Weak handshake negotiation

The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint;

Privacy information leakage

The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.

Summary

In this article, we have tried to discuss in detail about Insufficient Transport Layer Protection. In case you missed our last two posts, you can head over to the OWASP Top 10 section to read more about the top mobile and web threats. We will continue this series in the coming weeks to discuss each threat in detail.

Source: OWASP