e-Zest members share technology ideas to foster digital transformation.

Mobile app security: Introduction

Written by Kuldeep Shinde | Jan 11, 2017 4:59:15 AM
Mobile application security is nearly zero today.

Mobile technology has been the next big innovation that has been driving tremendous benefit and value in IT space after web. Every business is trying to get this smart solution on their finger tips for deeper reach. The disruption has been huge in every domain right from banking, retail to health sector. But as these solutions are coming down on smart mobile devices the current IT world is rarely bothered about the amount of private data store shared on mobile phones.

Over that, barely any of the innovation agencies are thinking about security of the personal and private data that has started residing on the mobile devices. The trend is pretty much the same as it was for initial times of dot-com boom, where solutions were more focused on experiences, engagement and adoption and very little on the security breaches.

Going through the stats available on internet, the 2016 report on App security from a leading institution on IT security says that 90% of app had major security vulnerabilities. More concerning about this survey is, even the consumer in the space fail to realise this apps are not safe, which means even the awareness of security around mobile application is very low at end user level.

Even though, the security critical tech-organizations are extending their conventional security frameworks for web to mobile. OWASP (Open Web Application Security Project) a non-profit organisation took up the responsibility of differentiating and standardising security risks for mobile channel.

OWASP research has come up with top ten mobile risks as stated below:
  •     M1: Weak Server Side Controls
  •     M2: Insecure Data Storage
  •     M3: Insufficient Transport Layer Protection
  •     M4: Unintended Data Leakage
  •     M5: Poor Authorization and Authentication
  •     M6: Broken Cryptography
  •     M7: Client Side Injection
  •     M8: Security Decisions Via Untrusted Inputs
  •     M9: Improper Session Handling
  •     M10: Lack of Binary Protections

Even though every risks stated above are important for security, I would like to focus on discussing the top three important points which have lower awareness even being crucial for security and at last the 10th for binary protection extending it for defensive programming.

M1 Weak Server Side Controls -

Mobile applications will work as thick clients which will be responsible for the application layer stack for the complete solution. And majorly the core of business implementation will reside on servers which will serve these mobile clients. Hence it is important to have robust server side protection schemes.
Most of the server side provide REST integration points which are generic and can be adopted by any other channel with mobile. Hence, the authentication and token mechanism play an important role in covering for security. The current web standards for REST authentication follows OAUTH for validating any request flowing down to the server. The goal is to provide strong session management and as the severity of the transaction is increasing we should make sure implementing stringent token authorization.
Using right HTTP method, even though GET has been fast and light for response, no sensitive information should be passed using this method.
Finally the most important measure is business logic flaws in which it must be made sure that no intermediate step can provide information if the penetration tester is trying to access the server controls then every request should be accepting valid and dependent inputs considering at a particular step to serve the business implementation.

M2 Insecure Data Storage -

Mobile platforms have two ways of storing data on device which is SQLite database or file system. According to my analysis, both are prone and can be accessed in worst case by rooting an android device or jail breaking an iPhone.
The next step can be to encrypt all the information using ciphers in database, but that will start affecting the performance of the application as the amount of data grows.
So the ideal strategy would be, not encrypting everything, but only the sensitive data; as the severity increases it is necessary to not to store data on device but safeguard them on server components. E.g. banking information or credit card details. Most of the banking applications do not store data on mobile device storage space and is fetched from server every time it is requested.

M3 Insufficient Transport Layer protection-

Mobile devices are more connected to internet via Wi-Fi after cellular data. Eavesdropping can start right from local intranet.
Every app should be designed to securely work in this scenario. SSL/TLS is mandatory for any mobile to communicate to their server control.
Apart from that, SSL certificate validation and maintenance should also be planned regularly.
Additionally server controls can have device registration, authorisation with their MAC address for further strengthening the security.

M10 : Lack of Binary Protections and Defensive programming-

This is the most crucial bullet in context of security for any mobile application and if taken care can enable to avoid and also cover most of the above security measures. Even though the two top mobile development platform do provide obfuscation and code protection by their default compilers, it is mandatory for the organisation to validate their binaries with thorough testing around reverse engineering. There are many tools available for verifying all the vulnerabilities due to lack of binary protection.

https://www.owasp.org/index.php/Mobile_Top_10_2014-M10

Few of the good practices for programming for security -

  • Manage to avoid your code integrity and additional code getting added into your system.  
  • Validate all the third party libraries.
  • For cache management, make sure you invalidate all the cache whether in memory or temporarily stored.
  • Avoid the use of unique identifiers, even if used, make sure they are diversified and different for every client, as breach in a single client doesn’t allow break in the complete system. Even GUI caching should be managed properly with deallocating the information and only caching the view components.
  • Inter-process communication is most prone to hacks. Avoid sharing or implementing critical transaction on this. Care should be taken to avoid in android for broadcast receivers and content providers.
  • Managing and storing the authorisation detail; even if keychain seems to be protective in IOS, this cannot withstand Jailbreak attack. Hence, the client should be only storing time based tokens for authorisation instead of user credentials. Also saving settings should be specific to the mobile client and not for the complete account for the user on the system.

Reference links:
https://www.owasp.org/index.php/Mobile_Top_10_2014-M10
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
http://www.informationweek.com/mobile/mobile-applications/mobile-app-development-5-worst-security-dangers/d/d-id/1204488
https://www.nowsecure.com/resources/secure-mobile-development