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:
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:
"Understanding Web Service Security Concepts" in Understanding Oracle Web Services Manager
"Web Service Security Standards" in Understanding Oracle Web Services Manager
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.
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 Using the Local Database in MAF AMX For more information on the GeneratedPassword, the encryptDatabase (and its counterpart, decryptDatabase), see and How to Encrypt and Decrypt the Database. For a sample application, see the StockTracker sample in the PublicSamples.zip, as described in MAF Sample Applications.
Note:
Always use the GeneratedPassword utility. Do not hard-code the key.
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 and 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/).
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 Side-Channel Data Leakage.
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 a list of policies that you may associate with REST web services, see Accessing Secure Web Services.
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 Configuring a MAF Application to Enable Two-Way SSL for Authentication.
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.
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 How to Designate the Login Page.
All features in a MAF application that require secure access must enable security, as described in 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 How to Configure Access Control.
Encryption becomes fallible because:
Applications use broken implementations or use known algorithms improperly.
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 Insecure Data Storage on the Device. Also, apply SSL to create secure web service calls as described in Insufficient Transport Layer Protection. MAF uses Oracle Access Manager for Mobile and Social IDM SDK for secure handling of credentials.
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. MAF protects against XSS through encoding.
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. Application sandboxing addresses CSRF concerns.
Also consider disabling application features (particularly application features with Remote URL content) access to the native container. You can prevent selected application features within a MAF application from accessing the native container. For example, your MAF application includes an application feature that references remote content from a web application that you do not trust (Remote URL content application feature). In this scenario, you prevent this specific application feature from accessing the native container, as shown in the following example:
<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="false"/>
The default value of the allowNativeAccess property is true.
The URIs that 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 Enabling a Core Plugin in Your MAF Application, you can configure a MAF application to limit the device's capabilities that a 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
SMS
phone
push notifications
locally stored files
Tip:
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 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 .
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 How to Use Verbatim Component and How to Use Output HTML Component. See also Security Decisions From Untrusted Inputs.
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.
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 Using Custom URL Schemes in MAF Applications. See also 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 .
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.
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 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.
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 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 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.