If you are looking for the complete guide for a level of security, You must refer to "Mobile Application Security Verification Standards by Open web application security project (OWASP MASVS). MASVS provides levels of security required based on the nature and use of your application. MASVS has Detailed verification requirements. The security requirements are categorized such as Architecture, design & threat modeling and Data storage and privacy, etc... MASVS-L1 is the basic level of security requirements recommended by OWASP.
MASVS-L2 lists additional defense-in-depth measures such as SSL pinning. If you achieve the MASVS-L2 level does not cover the root/jailbreak detection and Tampering. Root/jailbreak detection and Tampering is included in the MASVS-R. But MASVS-L2 is recommended for applications such as mobile banking and with a little effort, it is really easy to bypass SSL Pinning. If you want to know more about bypassing SSL Pinning with Inspeckage, Please refer to my previous writing.
Implementing SSL Pinning correctly and securely means, implementing the controls that prevent bypassing SSL Pinning as well. Therefore the following are the three main controls to consider if your application needs to be protected from intercepting traffic and achieve MASVS-L2.
MASVS-L2 lists additional defense-in-depth measures such as SSL pinning. If you achieve the MASVS-L2 level does not cover the root/jailbreak detection and Tampering. Root/jailbreak detection and Tampering is included in the MASVS-R. But MASVS-L2 is recommended for applications such as mobile banking and with a little effort, it is really easy to bypass SSL Pinning. If you want to know more about bypassing SSL Pinning with Inspeckage, Please refer to my previous writing.
Implementing SSL Pinning correctly and securely means, implementing the controls that prevent bypassing SSL Pinning as well. Therefore the following are the three main controls to consider if your application needs to be protected from intercepting traffic and achieve MASVS-L2.
- SSL Pinning
- Root/Jailbreak Detection
- Tampering and Repackaging
One of the most vital security control for a mobile application is "SSL Pinning". Most of the attacks are done with intercepting traffic with a proxy such as BurpSuite or ZAP. Therefore, a control that discourages intercepting traffic is required, and "SSL Pinning" is the main control used at the moment.
If your application is allowed to run on a rooted/jailbroken device, it is more vulnerable than an application with root/jailbreak detection. One I want to highlight is the possibility of bypassing SSL Pinning with hooks. You can read about bypassing SSL Pinning with "Inspeckage" here. So even if you discourage intercepting traffic with SSL Pinning, If you allow your application to run on a rooted/jailbroken device, still it is possible to intercept traffic from your mobile application.
Let's assume that your mobile application has SSL Pinning and root/jailbreak detection implemented. Still, there are ways to bypass SSL Pinning. You can read a nonconventional method of bypassing SSL pinning without a rooted device here. One common and conventional method is with "Frida" and most of these conventional methods are done with Repackaging the mobile application APK with a third-party tool like "Frida".
So if you are thinking about implementing "SSL Pinning", probably it is a security requirement of your application or you may want to achieve MASVS-L2. Implementing SSL Pinning will definitely, discourage attackers. But still, even a "script kiddie" might find a way to bypass SSL Pinning if your application is allowed to run on a rooted/jailbroken device.
SSL Pinning + Root/Jailbreak detection will further discourage attackers but a motivated attacker with some knowledge and skills can still Repackage the application with a tool such as Frida and still find a way to bypass SSL Pinning. Therefore tampering and repackage must also be implemented if you want to achieve better results with SSL Pinning.
This article intends to use with security testing, ethical hacking, and to increase the awareness of cybersecurity. Any malicious use is not intended.
Reference
