Mobile Top 10 2012 - M3 Insufficient Transport Layer Protection

Threat Agents	Attack Vectors	Security Weakness		Technical Impacts	Business Impacts
Application Specific	Exploitability DIFFICULT	Prevalence COMMON	Detectability EASY	Impact MODERATE	Application / Business Specific
When designing a mobile application, commonly data is exchanged in a client-server fashion. When this data is exchanged it traverses both the carrier network and the internet. For sensitive data, if the application is coded poorly, threat agents can use techniques to view this sensitive data while it's travelling across the wire. The following threat agents exist: Users local to your network (compromised or monitored wifi) Carrier or network devices (routers, cell towers, proxys, etc) Malware pre-exisiting on your phone	The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carriers network is harder than that of monitoring a local coffee shops traffic. In general targeted attacks are easier to perform.	Unfortunately, mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Detecting basic flaws is easy. Just observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration.		Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.	Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants.

Am I Vulnerable To Insufficient Transport Layer Protection?

The best way to find out if an application has sufficient transport layer protection is to verify that:

• SSL is used to protect all authentication related traffic as well as all traffic that transports a session token.
• If an SSL option is available, make sure it is used for all API's and services. This protects all data and session tokens that are exchanged from in-transit snooping. Remember to account for outside entities like 3rd party analytics companies, social networks, etc, and use their SSL versions even when an application runs a routine via the browser/webkit. Mixed SSL sessions should be avoided and may expose the user’s session ID.
• Only strong algorithms are supported.
• All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
• The application accepts certificates properly configured for that server. This includes being issued by an authorized issuer, not expired, has not been revoked, and it matches all domains the site uses.

How Do I Prevent Insufficient Transport Layer Protection?

How do I prevent

Example Scenarios

Example Scenarios

References

References