August 9, 2021

Mobile Application Testing

Let's discuss how can we improve the process of mobile application testing

Mobile Application Testing

Introduction

We provide comprehensive testing for the mobile applications and backend servers. According to OWASP Mobile Testing Guide, we utilize several methodologies to find ways to exploit the common vulnerabilities. The following items are possible ways to exploit a mobile application.

Private data stored in local storage without encryption
Misconfiguration of Cryptographic Algorithm
Client side authentication
Hardcoded key or token
Valid session after logout
WebView XSS
OTP password/PIN Code brute forcing

Not only the scenario as metioned above, we also design various possible attack scenarios with your application. Also, according to the OWASP MSTG and OWASP MASVS, we provide a standardized simulation process to ensure the quality of testing.

SOP

As shown above, the SOP of the mobile application testing is applicable for iOS and Android. If we find any vulnerabilities, we provide re-test servicce for clients that ensure all applications will be patched and secured.

Process of Testing

Automatic Analysis

Thanks to opensecurity, we utilize the Mobfs as our automatic analysis tool to save much time for static analysis.

Moreover, we adopt the Charles proxy to capture and observe requests and responses between application and backend server. In modern application design, it would take more authentication and server side data storage for more flexible usage so the API security is also a key to protect the application.

In general, we need to reverse the application to find if there is any hardcoded information within the application. We use the most popular reverse tool, dex2jar and jd-gui for android applications and hopper disassembler for iOS applications.

OWASP MASVS

There are several security requirements from MASVS. We list the categories so we can help you realize what we concerned for mobile application security

Data storage and privacy: we will verify private data, like encryption key or credential information, if they are stored securely and encrypted. DO NOT HARD CODE it in the mobile application. Hackers always can find a way out to scoop confidential data inside the application!

Cryptography: we will check if the algorithm is up-to-date. DO NOT USE cryptographic algorithms which are declared to have vulnerabilities or backdoors.

Authentication: we will check the authentication mechanism to see if the authentication process is done on the SERVER SIDE. DO NOT VERIFY the user crendential on the client side.
Network Communication: we will verify the backend server if it support TLS v1.2 or later. Old version of TLS is deprecated, so do not adopt the outdated version TLS protocol.
Interact with Native Platform: we will verify the webview to block javascript execution to avoid the cross-site scripting. Even though modern browsers like google chrome or firefox have mechanisms to block javascript, in mobile webview pages, we need to block in application by engineers.
Code quality: we will confirm if binary codes are minimized and the compiler provides some security features such as disabling debug function or debugging symbols.
Resiliency against reverse engineering: the application binary file should be obfuscated to increase the difficulty to reverse the logic of the application. Also, applications can provide detections for root/jailbreak or running in an emulator.