We have reached the point where a mobile phone might have more vital information than a desktop or laptop computer, including personal, financial or any other type of confidential information. However, while a lot of effort and resources have been invested over time in securing networks, servers, applications, databases and IT assets, the same is not equally true for mobile devices. It is not that smartphones are insecure, but rather that much work needs to be done in the mobile devices arena, in terms of security.
Web Apps vs. Mobile Web Apps
Securing a standard Web application can be a daunting task, given the level of exposure subjected to the application. HTTP may be the simplest scenario to ensure standard security procedures are applied -- and it’s the reason why many companies tend to develop a mobile Web version of their applications -- but such mobile applications must balance security, functionality and user experience.
Let’s say your application offers simple searches, basic information display and straightforward business logic. In that case, a mobile Web version would probably be your best option. However, if more complex tasks are required and you need to provide a better user experience, you may want to consider developing a native application for the device.
In terms of providing security for Web applications, we can define this as achieving data Confidentiality, Integrity and Availability (CIA) by implementing controls such as authentication, authorization, input validation and data protection, among others. The same can be said for mobile versions of those applications.
In order to make sure your application is secure, there are a number of options in today’s market such as source code review, penetration testing, black box/grey box/white box assessments, etc. Such choices are available via automated tools, or performed by humans, SaaS (Software as a Service), or a combination of the aforementioned. There are several options available on the market that can meet your needs, and most of them will work for you as long as your application was developed in a popular technology (such as Java or .NET).
For mobile developers, however, there are some general guidelines that must be considered for a mobile Web application project. In order to minimize security vulnerabilities, it is important to avoid the following:
Sending sensitive information over a URL: Avoid sending by phone any type of sensitive information, such as usernames, passwords, credit card numbers, SSN and IDs, as this will be stored in the phone’s browsing history and in other places like proxy servers, allowing anyone with access to your phone to impersonate you just by accessing that same URL.
Persistent session: Terminate your user session after a finite period of time, depending on the application’s criticality, in order to safeguard your session information from theft.
Not using SSL/TLS: Some devices are not capable of handling a secure connection; therefore, certain applications offer the option of authenticating the user via a non-secure channel. This should be avoided at all times.
For some companies, though, providing a lone mobile version of their current Web application is not enough; there is often a desire to develop a native application for users to enhance the user experience and the application capabilities. It is important to take into consideration the diversity of mobile devices and to determine which of those you are going to provide a native application.
The current list of platforms for mobile devices is extensive, and inevitably you will have to support at least a couple of them in to attain a broader range of users. You may even have to support different versions of the same platform due to compatibility issues. Aside from all the developing challenges, you must still consider the following recommendations when developing a native mobile application:
Storing sensitive data: Do not store sensitive data in easy-to-read text under any circumstance. Such means may be easily accessed. If you must store sensitive data, ensure you are using a standard encryption algorithm available for your platform.
Using device API: For common tasks, you should use the Application Programming Interfaces (API) that are already provided, instead of developing your own libraries or functions or using third-party components. This will increase efficiency and assure compatibility among versions, while providing assurances associated with using those standard and secure components provided by the manufacturer.
Authentication: It is highly recommended to activate your device’s authentication mechanism and to re-authenticate the user each time access is needed. While it is true that most smartphones offer password locks, sensitive applications must not rely on that action alone. It is highly recommended to add another layer of security such as: OpenID, OAuth, or SAML.
So what’s the best option?
Given the numerous challenges and solutions out there – what is one to do? Chances are you already have a Web services implementation in place that enables your applications to interact and exchange data throughout your organization. Web services allow you to separate the business logic from the front end while providing you a simple way to access and manage data. A non-Web approach on the front end (device’s native client), combined with Web services interacting on the back end, is the optimal approach.
Following this route, you don’t have to worry about storing any information in the device, and therefore don’t need to worry about exposing your database connections or server’s location. Security will be controlled at one single place, since everything will be done at the back end for all applications (Web, non-Web, mobile, etc.). This will also improve user experience.
If you decide to implement a client/server approach by using native clients and Web services, however, then the following security recommendations apply:
Use SSL/TLS at all times.
Do not store any information on the client side; after all, you won’t need to.
Re-authenticate the user every session; that is, every time the application is opened.
Do not store credentials for the Web service(s) on the device. Furthermore, avoid connecting to the Web service directly at all costs. Rather, send your request to the main server and redirect the user request to the appropriate Web service.
A session ID schema could be implemented, just as with a Web application. You would have the session on the client (device) and that’s the only information you will need to exchange, instead of sending credentials with every request.
When you decide you want to offer content to your mobile device users, it goes without saying that security is a primary concern. However, these issues can be mitigated with the proper planning and advance response. Thus, one should not shy away from mobile but rather figure out the best methods to guarantee security for your users and your data. Depending on your application criticality and exposure, you can decide how secure your application must be and what controls you are going to implement in order to achieve that holy grail balance between functionality, security and ease of use.
Leonel Navarro is the Information Security Practice Manager and business leader for Softtek, as well as a certified project management professional and certified information systems security professional. Navarro's 10 years of experience in IT operations with teams based in Mexico, the United States and China, combined with critical customer-facing positions he has held, enable him to perform the overall coordination of the sales, marketing, product management and strategic alliances strategy for Softtek's Information Security Service offering while overseeing the delivery of those services with existing clients. He has participated as a guest speaker at various conferences and has published several white papers. He holds a Bachelor in Electrical Engineering & Computer Architecture from ITESM.