Mobile Application Testing

Mobile Application Testing

Owing the ubiquity of the smart phone and tablet, many organisations are producing mobile applications either for their staff or clients. It is vital that these handle and use data in a secure and sensible fashion. As well as the risk of these devices being used over the internet these devices are at a high risk of being stolen. CNS will evaluate the security of the application, how does it handle and store data? how does it transmit data? does it manage sessions properly?. CNS will assess the application from both an authenticated and unauthenticated point of view (I.E an authorised user or someone who has stolen the device).

There are a number of different platforms and languages that make up what we now know commonly as an "App", testing the different types and parts of an application can take time, and of course methods of doing so vary depending on platform and type of application. The three that follow are typical examples found on most android and IOS operating systems:

1.      Web based applications - Javascript, CSS, HTML etc

2.      Native iOS/android/windows/blackberry applications - Objective C/Java etc

3.      Hybrid Applications - Native applications with embedded web views/content.

It is import to note that the techniques and languages used to write the applications, vary for each mobile platform. To this end it is important that each application is treated as a separate application and tested independently.

The process should always begin by taking in an overview of how the application works and what it does, one should also note the type of application as mentioned above as this will affect how the testing proceeds. Once determined there are a number of steps we will take to identify any potential weakness in the way the application works/stores or transmits data.

After observing the application and noting how it works and its precise function we can start to look at how the application actually communicates with the server or other systems, it is important to note that the end users handset or mobile device, should be treated as if it is compromised or stolen. Any security that is based on the client side installed application exists under the control of the attacker and can be disabled or modified, this also applies to secure storage. For example is data is stored on the device in an encrypted way, if the key is also stored on the device (to enable the user to read the data) then the key can be recovered and used. This does not mean that client side security mechanisms should not exist, but security must exist on the server side as well. CNS Hut3 will using a custom test rig, intercept messages from the mobile device to the server, these messages can then be manipulated and the responses evaluated. This will broadly follow the same steps as an OWASP application test, e.g are messages encrypted, are sessions handled properly, code injection etc.

In addition to evaluating the security of the messages, CNS Hut3 will evaluate the security of the application on the device. How is data stored, are authentication details stored locally, does the application rely on the security of the phone, does the application validate its own certificate etc?

It is vastly more efficient if we are given the source code and allowed to conduct a review of this code.

This approach can be roughly broken down into:

1.      Application Mapping

2.      Client Attacks

3.      Network Attacks

4.      Server Attacks

 

Mobile Application Testing Process Flow Diagram