Fusion Middleware Documentation
Advanced Search


Send Feedback | Print | PDF | ePub | Mobi
Developing Mobile Applications with Oracle Mobile Application Framework
Close Window

Table of Contents

Show All | Collapse

20 Understanding Secure Mobile Development Practices

Mobile Application Framework provides protection from common security risks identified by the Open Web Application Security Project (OWASP), which are described in the following sections:

20.1 Weak Server-Side Controls

Build security into a mobile application. Even in the earliest stages of designing a mobile application, you must assess not only the risks that are unique to mobile applications, but also those that are common to the sever-side resources that the mobile application accesses. Like their desktop counterparts, mobile applications can be made vulnerable by attacks on the backend services that store their data. Because this risk is not unique to mobile applications, the standards described by the OWASP Top Ten Project (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) also apply when you create mobile applications. Because client applications running on mobile devices can be vulnerable, do not use them to enforce access control. Because this function should be performed by the server-side application, MAF does not provide anything out-of-the box for validating data sent from the client. You must ensure that the data intended for a mobile application is valid. For more information, see the following:

20.2 Insecure Data Storage on the Device

Shortcomings in a mobile application's design can make local files accessible to users, thereby exposing sensitive data stored on a device's local file system. This data may include usernames and passwords, cookies, and authentication tokens. Although most users may not be aware that their data is vulnerable—or that it is even stored on the device itself—a malicious user could exploit this situation by having the tools to open the local database and view credentials. When assessing the security requirements for an application, you should assume the likelihood of a phone falling into the wrong hands. MAF provides the API to secure data stored on the device by encrypting the device database and local data stores.

20.2.1 Encrypting the SQLite Database

MAF's embedded SQLite database protects locally stored data. MAF applications do not share the SQLite database; the application that creates the database is the only application that can access it. Further, only users with the correct username and password can access this database. The AdfmfJavaUtilities class enables you to create keys to secure the password for this database and also to encrypt the data stored within it. To provide a secure key to the database, the AdfmfJavaUtilities class includes the GeneratedPassword utility class that generates a strong password and then stores it securely. The AdfmfJavaUtilities class also provides the encryptDatabase method for encrypting the database with a password. For general information about the SQLite database, see Chapter 10, "Using the Local Database" For more information on the GeneratedPassword, the encryptDatabase (and its counterpart, decryptDatabase), see Oracle Fusion Middleware Java API Reference for Oracle Mobile Application Framework and Section 10.2.7, "How to Encrypt and Decrypt the Database." For a sample application, see the StockTracker sample in the PublicSamples.zip, as described in Appendix F, "Mobile Application Framework Sample Applications."

Note:

Always use the GeneratedPassword utility. Do not hard-code the key.

20.2.2 Securing the Device's Local Data Stores

You can store files in the local file system programmatically on both the iOS and Android platforms using the adfmfJavaUtilties class' getDirectoryPathRoot method. Using this method provides agnostic access to store application data on the device. The following options are available for this method:

  • Temporary directory

  • Application directory

  • Cache directory

  • Download directory

Tip:

When users synchronize their devices to their desktop computers, the data stored in the device's Application directory is transferred to the desktop system where it can be exposed. Store data in the Temporary directory. For iOS, data stored in the temporary directory is not synchronized with the desktop when the device is synchronized using iTunes.

For any files that require security, you can encrypt and decrypt them using the Java cryptographic APIs (javax.crypto). For more information on the javax.crypto package, see Java Platform, Standard Edition 1.4 API. For more information, refer to Oracle Fusion Middleware Java API Reference for Oracle Mobile Application Framework and Section B.3, "Accessing Files Using the getDirectoryPathRoot Method." See also the "File System Basics" section in File System Programming Guide, available from the iOS Developer Library (https://developer.apple.com/library/).

20.2.3 About Security and Application Logs

Ensure that no sensitive data can be written to log files because they can be viewed if the device is synchronized with a desktop computer. When users connect their iOS devices to a desktop system to synchronize data, the application log files are ultimately stored on the desktop in an unencrypted format. Log files synchronized from Android devices can be viewed using the Android Device Monitor tool. See also Section 20.4, "Side-Channel Data Leakage."

20.3 Insufficient Transport Layer Protection

Mobile applications may use SSL/TLS when accessing data over a provider network, or neither of these protocols if they use WiFi. Because provider networks can be hacked, never assume that they are safe. You should therefore enforce SSL when the application transports sensitive data and validate that all certificates are legitimate and signed by public authorities.

Because all of the endpoints used by a mobile application must be secured with SSL, MAF provides a set of web service policies that support SSL. For SOAP web services, MAF applications use the following policies:

  • oracle/http_basic_auth_over_ssl_client_policy

  • oracle/wss_username_token_over_ssl_client_policy

  • oracle/wss_http_token_over_ssl_client_policy

For REST web services, MAF supports a number of SSL-based policies. For more information, see Section 8.5.2, "How to Enable Access to REST-Based Web Services" and Section 21.4.12, "What You May Need to Know About Adding Cookies to REST Web Service Calls."

MAF provides a cacerts file seeded with entries of known and trusted Certificate Authorities. Application developers can add other certificates to this file, if needed. For more information, see Section 21.8, "Supporting SSL."

20.4 Side-Channel Data Leakage

Unintended data leakage can originate from such sources as:

  • Disabling screen shots (backgrounding) -- iOS and Android take screen shots of the application before backgrounding the application for improving perceived performance of the application reactivation. However, these screen shots are a cause of security concern due to the potential leak of customer data.

  • Key stroke logging -- On iOS and Android, some of the information entered via keyboard is automatically logged in the application directory for use with type-ahead capabilities. This feature could lead to potential leaks of customer data.

  • Debugging messages -- Applications can write sensitive data in debugging logs. Setting the logging level to FINE results in log messages being written for all of the data transmitted between the user's device and the server.

  • Disable clipboard copy and open-in functionality for sensitive documents displayed as part of the application. MAF currently does not provide the capability to disable copy and open-in functionality and is being targeted for a future release.

  • Temporary directories -- They may contain sensitive information.

  • Third-party libraries -- These libraries (such as ad libraries) can leak user information about the user, the device, or the user's location.

To prevent data leakage:

  • Do not log credential, personally identifiable information (PII), or other sensitive data to the application log. Store all sensitive information in the native keychain or an encrypted database or file system.

  • When debugging an application, review any files that are created and anything written to them.

  • Remove debugging messages before publishing the application.

20.5 Poor Authorization and Authentication

Weak authentication mechanisms and client-side access control both compromise security.

Although it may be easier for end users to authenticate a device using a phone number or some type of identifier (IMEI, IMSI, or UUID) rather than a user name and password, these identifiers can easily be discovered through brute force attacks and should never be used as a sole authenticator. Mobile applications must instead use strong credentials when accessing sensitive data. The authentication should reflect the user, not the device. Further, you can enhance authentication by using contextual identifiers (such as location), voice, fingerprints, or behavioral information.

A developer can use either the default login page provided by MAF or a custom login page that they create. For more information, see Section 21.5.2, "How to Designate the Login Page."

All features in a MAF application that require secure access must enable security, as described in Section 21.5.1, "How to Enable Application Features to Require Authentication."

Additionally, access control must be enforced by the server, not the client. Locating this function on the client mobile application is less secure. Access Control Service (ACS) allows developers to use roles/privileges defined on the server to enforce access control in the mobile application. Access Control Service is a RESTful service that could be implemented by application developers to filter the user roles/privileges that are valid for the application. While an application may support thousands of user roles, the service only returns the roles that you designate for the mobile application. For more information, see Section 21.4.16, "How to Configure Access Control."

20.6 Broken Cryptography

Encryption becomes fallible because:

  1. Applications use broken implementations or use known algorithms improperly.

  2. Data is insecure because of easily defeated cryptography.

In addition, Base-64 encoding, obfuscation, and serialization are not encryption (and should not be mistaken for encryption).

To encrypt data successfully:

  • Do not store the key with the encrypted data.

  • Use the platform-specific file encryption API or another trusted source. Do not create your own cryptography.

In addition to securing the embedded SQLite database using the encryption methods mentioned in Section 20.2, "Insecure Data Storage on the Device." Also, apply SSL to create secure web service calls as described in Section 20.3, "Insufficient Transport Layer Protection." MAF uses Oracle Access Manager for Mobile and Social IDM SDK for secure handling of credentials.

20.7 Client-Side Injection From Cross-Site Scripting

Because mobile applications draw content and data from many different sources, they can be vulnerable to Cross-Site Scripting (XSS) injections, which co-opt the user session. While MAF protects against XSS primarily through encoding, it uses whitelists as an additional safeguard.

Whitelisting protects MAF applications from CSRF attacks by allowing only the permitted domains to open within the application feature's web view. The URIs that are not included in the list automatically open within the device's browser, outside of the mobile application's sandbox.

In addition to injection attacks, mobile applications are vulnerable to Cross-Site Request Forgery (CSRF), where a malicious page performs an unintended action in a targeted application on behalf of a user through the cookies cached in a web browser that store user identity. The combination of whitelists and application sandboxing address CSRF concerns.

20.7.1 Protecting Applications Against XSS Through Whitelists

For MAF applications, XSS and CSRF attacks may occur in applications whose user interface is delivered through a remote server. When you configure a mobile application to derive its content from a remote URL, the overview editor provided by MAF enables you to create a whitelist of the URLs that deliver the content. Whitelisted URLs open with the MAF web view and can access specified devices features and services. As described in Section 13.1.1, "Enabling Remote Applications to Access Device Services through Whitelists," you can configure a whitelisted URI using a wildcard.

Caution:

To prevent an unintended URI from accessing device features, define the whitelist for specific target domains only. Use the wildcard carefully when defining a whitelisted domain; do not define wildcard-based whitelist configurations, which can be used for a wide range of URI (for example, avoid configurations, such as: <adfmf:domain>*.*</adfmf:domain> or <adfmf:domain>*.com</adfmf:domain>).

20.7.2 Protecting MAF Applications from Injection Attacks Using Device Access Permissions

The URIs that you whitelist can access data stored on the user's device and its various device capabilities, such as its camera or address book. Such access is not granted by default; as described in Section 21.6, "Allowing Access to Device Capabilities," you can configure a MAF application to limit the device's capabilities that a whitelisted URI can access to any of the following:

  • open network sockets (must be granted when user authentication is configured)

  • GPS and network-based location services

  • contact

  • e-mail

  • SMS

  • phone

  • push notifications

  • locally stored files

Tip:

In addition to the whitelist configuration, you can programmatically protect users against such security risks as fake login pages injected by XSS through the updateSecurityConfigWithURLParameters method, which detects changes in the login configuration and then prompts users to confirm the change by re-authenticating, as described in Section 21.4.7, "How to Update Connection Attributes of a Named Connection at Runtime." Additionally, MAF informs users whenever they open a secured application feature. Authentication can be deferred when the default application does not participate in security. For more information, see Oracle Fusion Middleware Java API Reference for Oracle Mobile Application Framework.

20.7.3 About Injection Attack Risks from Custom HTML Components

Using HTML to create a custom user interface component in a MAF AMX page may leave an application open to an injection attack. MAF provides two components for HTML content in MAF AMX pages: the <amx:verbatim> component and the <amx:outputHTML> component. Because the <amx:verbatim> component does not allow dynamic HTML, it is not susceptible to an injection attack. However, the <amx:outputHTML> component, which delivers dynamic HTML content through an EL binding, may be vulnerable when you configure its security attribute to none. By default, this attribute is set to high to enable the framework to escape various HTML tags and remove JavaScript, such as an onClick event. Because setting it to none enables iFrame components and JavaScript (which allows AJAX requests within the AMX page), you must ensure that the HTML and JavaScript are properly encoded. For more information, see Section 6.3.18, "How to Use Verbatim Component" and Section 6.3.19, "How to Use Output HTML Component." See also Section 20.8, "Security Decisions From Untrusted Inputs."

20.7.4 About SQL Injections and XML Injections

Mobile applications are vulnerable to SQL injections, which can enable an attacker to read the data stored in the embedded SQLite database.

To prevent SQL injections:

  • Application developers are required to validate and encode all data stored in the local database.

  • Application developers are expected to encode and validate XML and HTML content processed by the application.

20.8 Security Decisions From Untrusted Inputs

On both iOS and Android platforms, applications (such as Skype) may not always request permissions from outside parties, providing an entry point for attackers that may result in malicious applications circumventing security. As a result, applications are vulnerable to client-side injection and data leakages. Always prompt for additional authorization or provide additional steps to launch sensitive applications when additional authorization is not possible.

You must ensure that all of the data that the application receives from (or sends to) an untrusted third-party application can be subject to input validation. The client side XML input to the application must be encoded and validated. Although MAF AMX components can validate user input, data must be validated on the server, which should never trust the data it receives from a client. In other words, the server is responsible for ensuring that the XML, JSON, and JavaScript that is sent back and forth between it and the client is properly encoded.

When you configure the URL scheme that launches a MAF application from another application, you must validate the parameters sent through the URL to ensure that no malicious data or URIs can be passed to the MAF application. For more information, see Section 4.4, "Invoking a Mobile Application Using a Custom URL Scheme." See also Section 20.1, "Weak Server-Side Controls."

About JSON Parsing

Use MAF's JSON encoding API where possible. For scenarios requiring custom JSON composition, be careful when composing JSON with user-entered data. For more information about processing JSON data, see the Oracle Fusion Middleware Java API Reference for Oracle Mobile Application Framework.

20.9 Improper Session Handling

Usability requirements for mobile applications often require sessions to last for long periods. Mobile applications use cookies, SSO services, and OAUTH tokens for session management. Oracle Access Management Mobile and Social (OAMMS) supports OAuth tokens.

Note:

OAuth access tokens can be revoked remotely.

To enable proper session handling:

  • Configure session timeout in the Login Server connection to a value less than server-side session timeout.

    Do not use a device ID as a session token because it never expires. An application should expire tokens, even though doing so forces users to re-authenticate.

  • Ensure that proper best practices (see OWASP Top Ten Project, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) are followed for token generation on the server.

    Do not use session tokens that can be easily guessed or are poorly generated. A session token should be unpredictable and have high entropy.

    Oracle Identity Management (IDM) stack provides support for standards-based tokens (such as, OAuth Access Token, JWT Token) for use with mobile applications. MAF provides out of the box support for Oracle IDM OAuth server and Oracle recommends using such standards-based authentication mechanisms with MAF applications.

As described in Section 21.4.2, "How to Configure Basic Authentication," configuring an application that requires users to authenticate against a login server includes options to set the duration of the session and idle timeouts. By default, the duration of an application feature session lasts eight hours. The default time for an application feature to remain idle is five minutes. MAF expires user credentials when either of the configured time periods expire and prompts users to re-authenticate.

20.10 Lack of Binary Protections Resulting in Sensitive Information Disclosure

Using reverse engineering, attackers can discover such sensitive data as API keys, passwords, and sensitive business logic. To protect this information:

  • Store API keys and sensitive business logic on the server.

  • Do not store passwords in the application binary.

  • Never hard-code a password. Instead, use the GeneratedPassword utility described in Section 20.2, "Insecure Data Storage on the Device."

  • Because log files can be monitored, ensure that applications do not write sensitive information to the log files. See also Section 20.4, "Side-Channel Data Leakage."

  • Keep in mind that information stored on a file system (that is, stored externally from the mobile application). Store sensitive data in an encrypted database or file system, or in the native keychain. See also Risk 1: Insecure Data Storage on the Device.