30 Days Of Mobile Testing: Mobile security testing
The theme of today is mobile security testing:
30 Days Of Mobile Testing, day 3: Perform a mobile security test.
I have no idea how to perform mobile security tests. Luckily, even though I have no idea, I am well traversed in the delicate art of Google, and thus the first result sent me to the OWASP Mobile security project.
Not surprisingly, mobile security testing is a very large area, so I’ve decided to do a micro-security test run. Since I’m starting from scratch, I’ve randomly selected one “check” from OWASP’s neat checklist for doing mobile security testing. I’ll gather information on thischecks, and then apply them to an app on my own smart phone.
I’ve ended up with the following check: “Android Backup Vulnerability”
Android Backup Vulnerability
Infosec Institute has a very informative article about this Android vulnerability. In short, it’s possible to alter the way Android backups/restores an app. This allows an app to introduce a malicious BackupAgent to feed the backup process with custom files and data (Such as new apps) without your consent. To get around this vulnerability, Infosec Institute suggests the following:
If your app holds sensitive data, you can stop allowing users from making a backup of the app. This is done by placing the following line in the AndroidManifest.xml file: android:allowBackup=”false”
Okay. That was simple.
Every Android application must have an AndroidManifest.xml file in its root directory. To get access to the directory, you need a “rooted” Android device, otherwise you’ll see an empty folder. Rooting a device is pretty tricky, so consider thoroughly if you want to put your private phone through the ordeal. However, most security mobile testing requires a rooted device.
After some discussion back and forth, I’ve decided not to root my everyday phone. Instead, I found an example of how the file with the line would look like:
Done. That was one check. It looks so easy when I read it now, but I must admit that this post has been underway for some time. I needed to do an extensive amount of research on security testing and the check, simply because I’ve never worked with these things before. The same probably applies to future posts on mobile testing (And the new #30daysofsecuritytesting challenge).
What I’ve found is that the information I need is quite easy to come by, and that I learn a lot from these small challenges. I’d recommend anyone to try it out!
The 30 Days Of Mobile Testing is the creative effort of Ministry of Testing, and anyone can join in. See more at https://dojo.ministryoftesting.com/lessons/30-days-of-mobile-testing
I don’t follow a lot of blogs. My digital method of obtaining test knowledge goes through Google, and through whatever articles my colleagues or connections share on social media. I don’t enjoy traversing through endless mails or RSS feeds with notifications of new blogs that I might find useful.. So I just don’t. So for this post, I had to go into the great Internet.
Did the thought of a mobile test lab and the problems with updating it and running it ever keep you from doing mobile testing? Don’t be discouraged, there are still so many possibilities. I don’t own a place or work anywhere with access to a fancy and up-to-date mobile test lab. But that doesn’t mean that I can’t do a lot of testing!
I’ve made a series of test stories from my favorite test runs. During this test run I tested a company’s customer service, as well as their mobile website, from the conception that both parts of the product should be usable anywhere at anytime.