Mobile Testing Part IV: An Introduction to Mobile Security Testing

Mobile security testing can be problematic for a software tester, because it combines the challenges of mobile with the challenges of security testing.  Not knowing much about mobile security testing, I did some research this week, and here are some of the difficulties I discovered:

• Mobile devices are designed to be more secure than traditional web applications, because they are personal to the user.  Because of this, it's harder to look "under the hood" to see how an application works.  
• Because of the above difficulty, mobile security testing often requires tools that the average tester might not have handy, such as Xcode Tools or Android Studio.  Security testing on a physical device usually means using a rooted or jailbroken phone.  (A rooted or jailbroken phone is one that is altered to have admin access or user restrictions removed.  An Android phone can be rooted; an iPhone can be jailbroken. You will NOT want to do this with your personal device.)
• It's difficult to find instructions for mobile security testing when you are a beginner; most documentation assumes that you are already comfortable with advanced security testing concepts or developing mobile applications.

I'm hoping that this post will serve as a gentle introduction for testers who are not already security testing experts or mobile app developers.  Let's first take a look at the differences between web application security testing and mobile app security testing: 

• Native apps are usually built with the mobile OS's development kit, which has built-in features for things like input validation, so SQL injection and cross-site scripting vulnerabilities are less likely.
• Native apps often make use of the data storage capabilities on the device, whereas a web application will store everything on the application's server.
• Native apps will be more likely than web applications to use biometric data, such as a fingerprint, for authentication.

However, there are still a number of vulnerabilities that you can look for in a mobile app that are similar to the types of security tests you would run on a web application.  Here are some examples:

• For apps that require a username and password to log in, you can check to make sure that a login failure doesn't give away information.  For example, you don't want your app to return the message "invalid password", because that lets an intruder know that they have a correct username.
• You can use a tool such as Postman to test the API calls that the mobile app will be using and verify that your request headers are expected to use https rather than http.
• You can test for validation errors. For example, if a text field in the UI accepts a string that is longer than what the database will accept, this could be exploited by a malicious user for a buffer overflow attack.

If you are ready for a bigger testing challenge, here are a couple of mobile security testing activities you could try:

• You can access your app's local data storage and verify that it is encrypted.  With Android, you can do this with a rooted phone or an Android emulator and the Android's ADB (Android Debug Bridge) command line tool.  With iPhone, you can do this with Xcode Tools and a jailbroken phone or an iPhone simulator.  
• You can use a security testing tool such as Burp Suite to intercept and examine requests made by the mobile app.  On Android, unless you have an older device running the Lollipop OS or earlier, you'll need to do this with an emulator.  On iPhone, you can do this with a physical device or a simulator.  In both instances, you'll need to install a CA certificate on the device that allows requests to be intercepted.  This CA certificate can be generated from Burp Suite itself.  

These two testing tasks can prepare you to be a mobile security testing champion!  If you are ready to learn even more, I recommend that you check out the online book OWASP Mobile Security Testing Guide.  This is the definitive guide to making sure that your application is free of the most common security vulnerabilities.  Happy hacking!