Kony lays out the 5 most common mobile security vulnerabilities and ways mobile application developers can surmount those issues
With the increasing adoption of mobile application development among both small and large organizations, security is a top concern – but are businesses focusing on the right issues? Are developers approaching potential vulnerabilities in the right way to ensure data safety and maintenance of a business’s mobile strategy? This article takes a look at misconceptions about the five most common mobile security vulnerabilities and how they can be addressed.
Weak server-side controls
This issue encompasses almost everything a mobile application can do badly that does not take place on the phone, such as the related backend services and infrastructure that support the mobile environment.
Biggest misconception
It is simply not true that application programming interfaces consumed by mobile devices are only consumed by mobile devices. The reality is most API services on the web are accessible even without the mobile app they were created for. Hackers can sniff out the wireless network or perform a man-in-the-middle attack to discover the API calls being made, modify them and attack the API directly by invoking the calls without the mobile app. Generally, the industry does a bad job of making sure that APIs are restricted to their intended mobile applications.
The solution
Secure coding and configuration practices must be used on the server side of the mobile application. Specifically, the API should securely verify the identity and permission of the caller.
Insufficient transport layer protection
Biggest misconception
Using Secure Sockets Layer/Transport Layer Security on a mobile app makes it secure. The reality is that man-in-the-middle attacks (even on SSL/TLS) are a lot easier than you think – especially if the attacker has physical access to the mobile device.
The solution
The mobile application should use certificate pinning or Hypertext Transfer Protocol public key pinning to prevent man-in-the-middle attacks. It can also use two-way authentication to gain nonrepudiation and authentication capability of both the server and client. Make sure all connections to the servers are encrypted (if applicable) using best practice configurations (i.e. currently TLS 1.2), do not accept user-accepted certificates as authorities, and make sure your SSL certificates are up-to-date and signed by a trusted certificate authority.
Unintended data leakage
Biggest misconception
It’s important to focus on protecting data from typical mobile app use cases. But the truth is there are a lot of other ways the data gets viewed, copied, cached, screen captured, backed up, logged, etc., that likely have not been considered, putting the data at risk. Even a custom keyboard app within the app could be “key logging” information without your knowledge.
The solution
Consider that the native mobile operating system often provides ways for users to copy/paste data, take screen captures with a mobile device, create mobile data backups using custom keyboards, and collect analytics with third-party apps. Consider the data and risk presented by these various scenarios and determine if it’s acceptable for the mobile app. If not, explicitly prevent these capabilities from within the mobile application or through control of the device with an Mobile Device Management/Mobile Application Management solution.
Poor authentication and authorization
Biggest misconception at authentication
The mobile app user who authenticated once before is still the same person. The user could have had their mobile device lost/stolen or had their credentials stolen from an insecure wireless network. Should the thief still be able to access his account information in his mobile banking app? Definitely not.
Biggest misconception at authorization
Assuming users are automatically authorized to do anything at any time because they have been authenticated. Consider a paid mobile app in which a user has cancelled his subscription, but because a persistent session had previously been authorized within the mobile app the user can continue to use the paid app for free. No hacking required.
The solution
Authenticate and reauthenticate the user periodically and before any sensitive action is performed. Authorize every request every time.
Lack of binary protections
Biggest misconception
Your mobile app is not at risk of being reverse-engineered, analyzed or tampered with. Believing you don’t need to protect your application binaries.
The solution
Protection varies by threat and mobile platform. Ensure your application is protected at runtime against analysis, monitoring and code injection. Also ensure that the mobile source code is encrypted and obfuscated. Integrity checks can help prevent modification of resources and source code. Preventing the mobile app from running on an insecure device, such as a rooted Android or jail-broken iPhone, also will help.
As more businesses turn to mobility, hackers are becoming smarter and more creative. It’s never been more important for information technology professionals and developers to keep these mobile security vulnerabilities in mind in order to protect the integrity of their businesses and the bottom line.
Editor’s Note: In an attempt to broaden our interaction with our readers we have created this Reader Forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
