How to Meet OWASP Security Guidelines for Your Mobile App? (10 Steps)

Mobile has grown tremendously all across the globe. In certain regions like India and Southeast Asia, there are more cell phones than people! Along with devices, mobile apps have also grown manifold. Suddenly, consumers are more confident with the convenience offered by their mobile phones.

While this extreme level of growth and convenience is exciting, it has also brought with it an extreme number of security risks, as user credentials, bank data, and other information are easily flying between devices and back-end systems worldwide.

Below, you’ll find the top 10 mobile security risks as defined by the OWASP Top 10 Project for Mobile. Understanding these risks and the OWASP security guidelines can help you prepare your app and protect yourself, your data, and your users.

OWASP security guidelines for your mobile app

M1: Weak server-side controls

As per the latest OWASP Top 10 Mobile report, weak server-side controls are the most exploited security threat in mobile applications. Most useful mobile enterprise applications rely on some sort of back-end services, which is why this is equally important.

Weak server-side controls include almost everything a mobile application can do badly that does not take place on the phone.

How to prevent weak server-side controls?

1. Use secure coding development lifecycle
2. Scan your applications
3. Get a detailed manual assessment

M2: Insecure data storage

Many developers assume that storing data on the client side will restrict other users' access to this data. Interestingly, most of the top mobile application security breaches have been caused by insecure or unnecessary client-side data storage. File systems on devices are no longer a sandboxed environment, and rooting or jailbreaking usually circumvents any protections.

How to prevent insecure data storage?

1. Encrypt all the sensitive information and data that are being stored in the application
2. Enforce proper permission for all the files which are being stored
3. Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system

M3: Insufficient transport layer protection

Typically, when a mobile application is designed, data is exchanged in a client-server fashion. This data can traverse both a carrier network and the Internet. For sensitive data, if the application is coded poorly, threat agents can use techniques to view it while it is in the mode of travel.

Obviously, you would not want sensitive information like passwords, credit card numbers, or other sensitive data traveling without some sort of encryption, generally HTTPS. To handle HTTPS correctly, you must also learn to code options around certificates in your mobile applications.

How to prevent insufficient transport layer protection?

To determine if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:

1. Are all connections, not just ones to servers you own, properly encrypted?
2. Are the SSL certificates in date?
3. Are the SSL certificates self-signed?
4. Does the SSL use high enough cipher strengths?
5. Will your application accept user-accepted certificates as authorities?

M4: Unintended data leakage

Unintended data leakage occurs when a developer inadvertently places sensitive information or data in a location on the mobile device that is easily accessible by other apps on the device. This insecure location could be accessible to other malicious apps running on the same device, thus leaving the device in a serious risk state.

How to prevent unintended data leakage?

There are some common leakage points that you have to monitor. It is important to threat model your OS, platforms, and frameworks to see how they handle the following types of features:

1. URL caching (both request and response)
2. Keyboard press caching
3. Copy/paste buffer caching
4. Application backgrounding
5. Logging
6. HTML5 data storage
7. Browser cookie objects
8. Analytics data sent to 3rd parties

M5: Poor authorization and authentication

Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor.

How to prevent poor authorization and authentication?

Avoid the following Insecure Mobile Application Authentication Design Patterns:

1. If you are porting a web application to its mobile equivalent, the authentication requirements of mobile applications should match that of the web application component.
2. Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device.
3. If client-side data storage is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials.
4. Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.
5. If possible, do not allow users to provide 4-digit PINs for authentication passwords.

M6: Broken cryptography

Broken cryptography attacks occur when an app developer wants to exploit encryption in his application. To exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process.

How can broken cryptography be exploited?

There are two ways in which an attack can occur - decryption of data via physical access to the device or network traffic capture, or malicious apps on the device with access to the encrypted data.

The following scenarios can result in such attacks:
1. Reliance upon built-in code encryption processes
2. Poor key management processes
3. Creation and use of custom encryption protocols
4. Use of insecure and/or deprecated algorithms

M7: Client side injection

Client-side injection results in the execution of malicious code via the mobile app on the client side, which is the mobile device. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data forces a context switch, and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app.

How to prevent client-side injection?

More or less, following the best coding practices should help you out a lot:

For iOS:

1. SQLite Injection: When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query.
2. JavaScript Injection (XSS, etc): Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for dangerous JavaScript characters if possible, using a whitelist over the blacklist character policy before rendering.
3. XML Injection: use libXML2 over NSXMLParser

For Android:

1. SQL Injection: When dealing with dynamic queries or content providers, ensure you are using parameterized queries.
2. JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews (usually the default).
3. Local File Inclusion: Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).

M8: Security decisions via untrusted inputs

Developers generally use hidden fields and values or any hidden functionality to distinguish higher-level users from lower-level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper app behavior and even granting higher-level permissions to an attacker. This can be easily exploited using something called hooking.

Related Topic- Understanding OWASP Top 10 Mobile: Security Decisions Via Untrusted Inputs

Here is a nice presentation to help you understand more about the Android permissions model and the basis for this threat to be exploited.

M9: Improper session handling

As the name suggests, this issue is caused by the way session tokens are handled. While some of it might be intentional, enough care should be taken to add some kind of validation for the user.

Because mobile applications are used in such a way, many developers allow long or non-expiring user sessions or use session tokens that are too predictable. Many times, this is intentional because businesses want users to have fast access to purchasing and checkout so that sales can be made before the user has second thoughts. Reducing the need to constantly log into the application reduces friction for users.

How to prevent improper session handling?

To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session tokens properly over the life-cycle of a user's mobile app session.

M10: Lack of binary protection

A lack of binary protections within a mobile app exposes the application and its owner to a wide variety of technical and business risks if the underlying application is insecure or exposes sensitive intellectual property. A lack of binary protections results in a mobile app that can be analyzed, reverse-engineered, and modified rapidly by an adversary.

However, an application with binary protection can still be reversed by a dedicated adversary, so binary protection is not a perfect security solution. Binary protection only slows down a security review.

How to prevent a lack of binary protection?

First, the application must follow secure coding techniques for the following security components within the mobile app:

1. Jailbreak detection controls;
2. Checksum controls;
3. Certificate pinning controls;
4. Debugger detection controls.

Next, the app must adequately mitigate two different technical risks that the above controls are exposed to:

1. The app must adequately prevent an adversary from analyzing and reverse engineering the app using static or dynamic analysis techniques
2. The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its integrity at compile time and react appropriately to a code integrity violation.