Mobile Testing Security - Published Article

Mobile Security Testing

  1. Executive Summary

Mobile computing has become ubiquitous very quickly and the lines between personal phone and work related mobiles are blurred as employees and users use the same device for both.

In this context, the applications that are used on the mobile devices are at their most vulnerable state. The security model is so much different when compared to a web application or client/server that it warrants a specialized focus on this topic.


In this document, we will review the mobile landscape, various security threats, architecture/design and few examples of tools that a relevant to platforms to handle these threats. There will be recommendations of tools specific to platforms but this document is agnostic of any mobile platform.

  1. Introduction

In the last 2 years, the number of mobile devices sold worldwide is little over a billion and almost 1 million applications are available through marketplaces of the mobile platform providers.

Most of the business applications through the last 5 years were designed and built for Web or may be, to an extent Client/Server systems and quickly modified for mobile usage. When the design of the applications for mobile platform do not happen grounds-up, planned for the mobile landscape, several lapses in security may become existent. The testers should target to uncover these gaps in order to prevent issues in the areas of:

  • Authentication & Authorization: Ensure the user is who he/she is and has the right privileges
  • Integrity: Trust the data and application behavior
  • Confidentiality: Take care that the application data is privately managed

The means of achieving this is by denying several security hacking points like:

  • Encryption or lack of having one
  • Input validation – both inside and outside application
  • Prevent snooping by data filtering
  • Storing authentication tokens in application
  • Storing critical data on the device

When planning for security, the business priority has nothing to do with it as the kind of data that can be obtained by a hacker from any these applications can have an equally devastating effect.

Mobile security has two major areas to it –

  1. Mobile Platform/OS
  2. Mobile network.

We will explore each of the areas in detail.

  1. Mobile Security landscape


3.1 Mobile Platform/OS

Majority of the mobility platforms today provide a marketplace for Apps that are then downloaded into the device from the hosted space. The following choices are available:

  1. iOS – Defined by Apple for their smartphones and tablets and comes with many security features built in that can offer a good base for the application security. Data encryption is built-in and when the device is passcode locked, the data stays encrypted, unmodifiable and inaccessible (even to the app). While this is good, please note that this does not help when the device is in use. Additionally, the OS app area follows a “walled garden” approach. The applications cannot access private data without user’s approval.
  2. Android – This platform is somewhat more flexible and developer friendly than iOS which also means that there are more possibilities of security threats if applications are not defined carefully. The apps use permissions set for them in a “Manifest.XML” and developers are free to add or remove permissions depending on the need. This makes malware more common and of significant impact to the platform. However, the platform verifies possibility of malware being downloaded in the first place.
  3. Windows Phone – Similar to the other platforms Windows phone OS has several security features built in like platform integrity via “Secure boot” feature. This feature allows only verified apps and components to execute as well as make the code signed with a Microsoft certificate. Additionally, Windows phone encrypts both OS and data files. The apps in this platform are also sandboxed, preventing un-authorized access between applications.

While the platform/OS provides many security features, the applications should still need to plan for security as some of these features can be overridden by “User Approval”, hence lack of awareness of the user still causes security problems.

3.2 Mobile Networks

Mobile data networks have their own security protocols and vulnerabilities at the same time. Although there are several types of networks across the world, the following are a few of the most common types:

GSM: GSM networks are the most common ones for carrying mobile communication and data. Although this is considered to be most secure, there are several gaps in the security.

  1. Communication Channel: The encryption does not occur on the complete communication channel, but only from mobile to the base station.
  2. TMSI: The temporary mobile subscriber ID can be obtained by hackers, proven in many occasions that can give the position data of the user away.
  3. Authentication: The authentication is only unidirectional. Hence the user cannot be assured that the communication he/she receives is really the desired one.

All in all, GSM is an old network and has evolved on the overall security aspects piece-by-piece over the years.

Wi-Fi: One of the most convenient networking protocol in the world, almost all corporates use this across their physical locations. While hackers found that Wi-Fi networks are easy to break into, equal security measures can be taken to prevent such attacks:

  1. Attaching a wireless router into an unsecure switch port can expose the whole network to undesirable entities
  2. Malicious association can be achieved when “soft Access Points” are created for others to connect to instead of company access points

Several other issues like DOS, Network injection, MAC Spoofing etc. can be done however, equal measure of securing are available and being taken by organizations.

Next generation: There are other newer technologies like LTE and NFC which are beginning to mature and improve on their security vulnerabilities.

A mobile application should not just depend on the features of the platform or the network as they all have vulnerabilities and must plan for security in the application and thoroughly tested.

  1. Mobile Application Soft-Spots

Almost all of the enterprise mobile applications are tested thoroughly on the functional side but they miss things on the penetrative testing for security.

The following are a few soft spots for mobile security break which should be factored into testing.

  1. Credentials/Sensitive data on mobile: A hacker or a Malware can easily get access to the sensitive data stored on the mobile device. Unlike a web application, the possibilities are immense for such an attack. In Addition, it is relatively easy to reverse engineer the applications hence, no such important data should be stored on the application/device.
  2. System clean up: Data that is required to be stored in cookies/temp files during application execution must be cleaned up. Otherwise, this leaves a very easy target for anyone accessing the device.
  3. Data flow: A tester should be able to establish an audit of the data – What goes where, who got access, and how is it stored.
  4. Data sniffing: Data on the network can be easily sniffed using various tools. This is one reason why all data to and from device should be encrypted.
  5. Data injection: When user inputs are validated by the application on the device, the inputs will need to be validated again on the server side for unauthorized data injection/modification en route. This will ensure integrity of the data that comes in.
  1. Mobile Security Testing Strategy

With all the issues we reviewed so far, some are fairly serious while others are easier to manage. No matter what the vulnerability is, a security testing plan is something that assures, validates the prevention of the loopholes while repudiating the attacks.

While it is common to say that the security test plan depends on the specific needs of the organization, there are some critical areas that are a must in every security test plan.

  • User Access – Plan test cases around user access scenarios. This includes testing for:
    • Different access levels – Expected user access is withheld at different stages of application life cycle.
    • Jail-breaking/rooting – How the application behaves when the device is Jail broke. How does the access levels withhold or fail.
    • Privilege checks – Access to resources (like files, features) is as expected.
  • Data Input – As discussed earlier, inputs must be verified at every stage for integrity as well as expected source.
    • User Input should be verified against tampering.
    • Data could be sniffed over the network, hence encrypt.
  • Application execution – Plan to test against Network interfaces, communication with other resources, session management (expirations, integrity)
    • User session remains until the user logs off or planned timeout occurs.
    • Provide consistent server side operations for CRUD operations.
  1. Mobile Security Test Plan

The mobile security test plan generally should have a high level structure that encompasses:

  • Definition of security boundaries and expectations
  • Threat Modeling
    • Identify threats categorize them (with risk rating, probability, impact and mitigation)
  • Vulnerability evaluation of the application
    • Reverse engineering of the app code
    • Source code analysis with tools
    • Network monitoring
    • Runtime manipulation of data
    • Analyze against timestamp of data logs
  • Plan for specific areas of testing
    • Are there any financial transactions in the application
    • Are any non-application resources are modified
    • Integration points with other systems (outside the mobile device)


  • Metrics
    • Load testing for the application
    • Specifically identify the breaking points
    • Test for denial of service attacks
  1. Conclusion

Mobile application security is a vast area that has implications based on the exact requirements of the application. It depends a lot on the type of application being built and maintained. Outside of the functional testing, a separate approach should be done in parallel to security testing.


September 2, 2014

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013