Top 10 OWASP Mobile security risks and best solution on how to minimize them.

Mobile Application Security Tools

Ten OWASP mobile security risks with solutions for minimizing or avoiding them. According to OWASP, a not-for-profit charitable organization, the existing mobile application vulnerabilities are broadly classified as what needs to be mitigated immediately to ensure maximized protection for the mobile application economy.

1) Weak server Side controls: This is the first vulnerability reported, wherein the mobile application itself isn’t totally aware about the bad situation, that occurs exclusively on the server side. Any delay in action to mitigate these kinds of threats, causes a huge threat to the enterprise or organization thereby compromising and declining the sales revenue of the enterprise.

Solution for these risks: secure coding and configuration practices must be followed on the server side of the mobile application to prevent these types of issues.

2) Insecure data storage: a mobile application is capable of storing valuable information in the SQLite databases, log, Plist, xml data stores/manifest, binary data stores, cookie stores, SD card and cloud synced files. Poor encryption and decryption standards causes difficulties in securing these files, which leads to data exposure.

Solution for these risks: the best way to minimise this problem is to not store any significant information on the local storage or SD card of the phone unless necessary. Also, for securing assets do not perform hard coded encryption and decryption. For protecting databases, consider using SQLcipher for SQLite encryption.

3) Insufficient transport layer protection: the mobile application must be intermediately checked at regular intervals through a proxy for evaluation of SSL or Transport layer protection. Frequently verify the following

  • Are the connections to the servers that you own properly encrypted?
  • Were the SSL certificates up to date as well as self-signed?
  • Does your application allow user accepted certificates as authorities?
  • Does the SSL use high cipher strengths?

Solution for these risks: to prevent insufficient transport layer protection follow these steps

  • Use strong, industry standard cipher suites with appropriate key lengths.
  • Assume that the network layer is not secure and is susceptible to eavesdropping.
  • Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
  • Always require SSL chain verification.

4) Unintended Data Leakage: the security vulnerabilities without the developer’s knowledge causes unintended data leakage from the OS, frameworks, compiler environments and new hardwares .

Solution for these risks: threat model your OS, platforms and frameworks and see how they handle the below scenarios:

  • URL Caching (Both request and response)
  • Keyboard Press Caching
  • Copy/Paste buffer Caching
  • Application backgrounding
  • Logging
  • HTML5 data storage
  • Browser cookie objects
  • Analytics data sent to 3rd parties

Identify the default behavior of these from the OS, platforms, frameworks and prevent the occurrence by controlling it.

5) Poor authorization and authentication: storing the login information such as passwords locally in the mobile application causes poor authorization and authentication standards.

Using values that can be spoofed for geo-location and device identifier may bypass the client-side authentication process.

Solution for these risks: developer must assume that client-side authentication is easily bypassed by the attacker and then reinforce necessary authorization and authentication from server side, wherever applicable. Also, to check unauthorized code changes locally, developers must induce local integrity checkers inside the application.

6) Broken cryptography: there are two causes that led to break cryptography. First, the mobile app may use a process behind the encryption/decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data. Second, the mobile app may implement or leverage an encryption-decryption algorithm that is weak in nature and can be directly decrypted by the adversary.

Solution for these risks: do not use insecure-deprecated algorithms these have proven weakness against modern security such as RC2, MD4, MD5 and SHA1. Do not follow poor key management process as it may result in leakage of keys to the attackers.

7) Client-side injection: the best way to evaluate this vulnerability is to supply user specified values for validation in the client-side, disallowing code injection. The attackers target the data stored in the device for validating the credentials in the client-side. Improper user session handling results in client-side injection as the attacker might jailbreak the device and attempt for serious damage.

Solution for these risks: these are the Android best practices to resolve various injections.

  • SQL Injection: when dealing with dynamic queries or Content-Providers ensure you are using parameterised queries.
  • JavaScript Injection (XSS): verify that JavaScript and Plugin support is disabled for any Web Views (usually the default).
  • Local File Inclusion: verify that File System Access is disabled for any web Views.
  • Intent Injection/Fuzzing: verify actions and data are validated via an Intent Filter for all Activities.

8) Security decisions via untrusted inputs: the mobile application without any security is capable of accepting inputs from non-trusted sources through Inter Process Communication(IPC). The IPC entry points must undergo stringent input validation and prohibit the input driven attacks.

Solution for these risks: to prevent this, use white list of trusted inputs and restrict unauthorized access for IPC related entry points.

9) Improper session handling: improper session handling leads to poor authentication. Mobile application code must protect the user sessions cautiously with an authentication mechanism

Solution for these risks: To minimize this, avoid poor practice of session token maintenance. Verify that mobile application code creates, maintains and destroys the token properly over the lifecycle of user’s mobile app session.

10) Lack of Binary protections: the inbuilt binaries used in your mobile app could be reverse engineered and used in other third party apps and hosted in third party sites for illegal usage. Therefore it becomes necessary to protect your app binaries at all costs.

Solution for these risks: The mobile application must follow these coding practices to leverage security.

  • Jailbreak Detection Controls
  • Checksum Controls
  • Certificate Pinning Controls
  • Debugger Detection Controls

Suggested Blogs

Protect your mobile app against juice jacking fraud

Protect Your Mobile App Against Juice Jacking Fraud

Security breaches that include mobile devices are on the rise with the exponential growth of smartphones. Fraudsters will target any mobile device with more people using smartphones. Each operating …

Mobile App Code Protection

Code Protection: How to Protect Your Source Code 

Code protection describes the tactics and procedures used to protect source code from theft, unauthorized access, and misuse. Source code is the most important intellectual property of the …

Mobile app security

Mobile Application Attacks, Static and Dynamic 

Mobile apps have become an integral part of our daily lives. From social networking and entertainment to banking and communication, nearly everything can be done on a smartphone. Because sensitive …