Mobile Top 10 2012 - M3 Insufficient Transport Layer Protection
Revision as of 18:31, 28 January 2013 by Jason Haddix
|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|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:
||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.|
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