Mobile Top 10 2012 - M3 Insufficient Transport Layer Protection
|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 look at the application traffic through a proxy. Ensure that all connections, not just ones to servers you own, are properly encrypted.
General Best Practices:
- Assume that the network layer is not secure and may potentially be hostile and eavesdropping.
- Enforce the use of SSL/TLS for all transport channels in which sensitive information, session tokens, or other sensitive data is going to be communicated to a backend API or web service.
- 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.
- Use strong, industry standard encryption algorithms and appropriate key lengths.
- Use certificates signed by a trusted CA provider.
- Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
- Do not disable or ignore SSL chain verification.
- Only establish a secure connection after verifying the identity of the endpoint server with trusted certificates in the key chain.
- Alert users through the UI if an invalid certificate is detected.
- Do not send sensitive data over alternate channels, such as SMS, MMS, or notifications.
iOS Specific Best Practices
- CFNetwork is an API for creating, sending, and receiving serialized messages over a network. CFNetwork can be used to set up and maintain a secure SSL or TLS networking session with . It lets you add authentication information to a message and specify an SSL or TLS protocol version to encrypt and decrypt the data stream.
Ensure that certificates are valid, and fail closed The URL Loading API supports HTTP, HTTPS, FTP, and file resource types; these can be extended by subclassing the NSURLProtocol class. The normal way to interface to this API is via NSURLConnection or NSURLDownload, using an NSURL object as the input. Requests have a number of methods controlling their behavior—one method that should never be used is setAllowsAnyHTTPSCertificate. For almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength. Use the CFHTTPAuthentication API for secure communications over HTTP