Here at Fortify On Demand our engineers assess countless mobile apps. Being on both sides of the fence (static analysis and blackbox pentesting) we like to think we have a very holistic view of mobile vulnerabilities. This series is an educational resource for mobile app developers and testers exploring the newly minted OWASP Mobile Top 10 project, its categories, and how these vulnerabilities manifest themselves. We will explore the threats surrounding these vulnerabilities and in some cases look at insecure code and testing methods associated with them as well.
The Open Web Application Security Project (OWASP) has been categorizing, evangelizing, and publishing remediation information for web application security for 12 years. In 2007 OWASP released a project to categorize the 10 most prevalent web application vulnerabilities in order to educate developers and testers as to their manifestations and risks. The end goal being that they could be identified and reduced in web applications all over the world. The “OWASP Top Ten” project was a huge success.
In early 2012 OWASP realized that the application landscape had shifted. They enlisted the help of researchers to draft a Top Ten list for mobile applications. Fortify On Demand researchers lead and contribute to this project. Below we will be exploring the third category in the OWASP Mobile Top 10; Insufficient Transport Layer Protection.
M3: Insufficient Transport Layer Protection
When designing a mobile application, commonly data is exchanged in a client-server fashion. When this data is exchanged it can traverse both a 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 traveling across the wire. You don't want passwords, credit card numbers, or other sensitive data traveling without some sort of 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.
The following threat agents exist:
- Users local to your network (compromised or monitored wifi)
- Carrier or network devices (routers, cell towers, proxy's, etc)
- Malware pre-existing on your phone
- Hackers trying to attack you web services
The best way to find out if an application has sufficient transport layer protection is to look at the application traffic through a proxy. Find the answers to 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?
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:
Default classes in iOS handle SSL cipher strength and negotiation very well as of recent releases. The trouble comes when code is introduced 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, NSStreamSocketSecurityLevelSSLv3 or 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 exporting your certificate, including it in your app bundle, and anchoring it for your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallen
ge: 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.ALLOW_ALL_HOSTNAME_VERIFIER. This is equivalent to trusting all certificates.
In this write-up we have explored M3 Insufficient Transport Layer Protection in several contexts. Hopefully this information leads to more secure mobile apps. In February we will continue on down the Mobile Top 10 look at the rest of the categories. If some of this text look the same as the official Mobile Top Ten page, don't be alarmed, Fortify On Demand drafts the content and contributes it to OWASP ;)
If you would like more information on assessing your mobile apps, we recommend our easy to use cloud offering, Fortify On Demand. In this process your mobile apps are assessed statically and dynamically by our word class software and engineers. To schedule a “proof of value” free assessment, contact firstname.lastname@example.org and for technical comments or questions I can be reached at Jason.haddix –a.t- hp.com.
References and Resources:
- OWASP Mobile Top 10 - M3 Insufficient Transport Layer Protection
- OWASP IOS Developer Cheat Sheet
- Google Androids Developer Security Topics 1
- Google Androids Developer Security Topics 2
- Apple's Introduction to Secure Coding
- blog.securemacprogramming.com - SSL Pinning for Cocoa Touch
- Why Eve and Mallory Love Android