Skip to content

Security Recommendations

The SAP Cloud Platform SDK for Android provides a number of security features that you should familiarize yourself with before you start developing your mobile application.

This topic describes these features and provides some recommendations on how to use them to safeguard your app's data.

Password Protection

The SAP Cloud Platform Mobile Services allows you to apply a passcode policy to you mobile application. An application password helps secure your app's data in case an unlocked device is lost or stolen.

Use a passcode policy to require your user to provide an app password to log in to the app. The passcode policy lets you control the rules for the password such as the expiration period, minimum length, and character requirements for the password. See Defining Client Password Policy for more information about setting a passcode policy.

If the device has a fingerprint sensor, you can set the policy to allow the user to use a fingerprint to open the app. Users must also set a password in case the fingerprint cannot be read.

Note

The most secure policy requires a password without the fingerprint option. Refer to Understand fingerprint security for more information.

A user-provided password can be used to generate an encryption key for a secure store or offline database. See Encryption Utility for more information.

Encrypting Data

The SDK provides tools for encrypting data that is stored in the offline OData store and the secure store database.

Offline OData Store

You can encrypt data on the offline OData store on the device using a call to setStoreEncryptionKey:

1
2
3
4
...
OfflineODataParameters offlineODataParameters = new OfflineODataParameters();
offlineODataParameters.setStoreEncryptionKey("aSecretkey2Encryptdata");
...

You must use a PBKDF2 function to generate strong keys for encryption. One way to to generate encryption keys while ensuring high entropy is using the Encryption utility. This utility uses a thousand iterations to generate keys. See Encryption Utility for more information.

Encryption keys should not remain in memory for the entire session of the application lifecycle. Instead, keys should be generated in real time and wiped after use.

Secure Store

Secure Store provides 256-bit AES encryption of data stored in a SQCipher database. It provides an additional layer of verified encryption in case the device is rooted and the default security checks are compromised.

SAP recommends using Encryption Utility to generate an encryption key of sufficient complexity.

You can also use a time-based (expiry) control to wipe sensitive data from the mobile device if the application has not communicated with its servers for a given period of time.

Cache Management

Sensitive information should stay in memory for as little time as possible. A memory cache can be susceptible to a memory dump and time-based type of control to expire data after an interval. See CWE-316: Cleartext Storage of Sensitive Information in Memory for more information.

In Android, string objects are immutable and should be avoided when storing sensitive information. Instead, use a char array and reset its values when not needed.

Even if references to immutable objects are removed or nulled, they may remain in memory until "garbage collection" occurs (which cannot be forced by the app).

For sensitive data, consider using a SecureStoreCache(link).

File Privacy

If your app manages files such as downloaded attachments or images captured using the device camera, you should consider how these files are stored and how they can be passed to external viewers.

Android provides content providers that you can use to manage this data. See Content providers for more information.

TLS Versions

TLS 1.1 and earlier versions are vulnerable to security attacks. Mobile apps built using the SDK must use TLS version 1.2 or above and must support Perfect Forward Secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange and AES-128 or AES-256 symmetric ciphers.

SAP Cloud Platform servers deny connections from clients requesting TLS 1.0 and TLS 1.1. For more information on TLS support in the SDK see TLS Versions.

Use a network testing tool such as Nogotofail to test for network security issues. Nogotofail is an open source tool from Google that exposes known TLS/SSL vulnerabilities and configurations issues. It is designed to run on-path so the network traffic can go through it.

Use this tool for:

  • Finding bugs and vulnerabilities.
  • Verifying fixes and watching for regressions.
  • Understanding what applications and devices are generating what traffic.

Self-signed Certificates

By default, apps running Android 7 and above only trust system Certificate Authorities (CA). These apps will not trust certificates signed by any other CA even if these certificates are installed on the device. Previously, Android apps trusted both system and user-installed CAs.

If you want your app to trust certificates from another CA, you must provide a network security configuration file that specifies that these certificates should be trusted. See the Network Security Configuration topic in the Android Developer documentation for more information about this configuration file.

Important

If you relaxed security while debugging your app, make sure that you re-apply any required security settings, such as self-signed certificates, before releasing your app.

Certificate Pinning

Typically, an application accepts any certificate signed by a trusted certificate authority. Certificate pinning ties a particular X509 certificate or public key with a server.

By enabling the application to be "pinned" to the server's public key, you ensure that only that key will be allowed for connections to the server. By removing dependence on external certificate authorities, the attack surface is reduced.

The certificate is typically pinned during development.

For instructions on how to pin certificates with OkHttp, see okhttp3 CertificatePinner Class.

For instructions on how to pin certificates on Android 7 and above devices using the network security config file, see Pinning Certificates.

Sharing Credentials Between Apps

If a device has multiple applications installed that authenticate against the same server, you may want to ensure that the user does not have to reauthenticate when the second app is opened.

You can do this with OAuth and Chrome Custom Tabs. Chrome will share the cookies and saved credentials if the authentication request is made to the same URL.

Preventing Screenshots

Allowing your app users to take screenshots of your app is a security risk because a screenshot could include sensitive corporate or personal information. The Android OS also takes screenshots of the application to display in the Recent Apps menu.

Screenshots are stored on the device unencrypted and, therefore, could be recovered by a malicious application or attacker.

To prevent your users from taking screenshots of your app, use the following code:

1
2
3
getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE);

setContentView(R.layout.activity_main);

Note

This code also prevents the screen from being shared with third-party screen sharing apps like Vysor.

See also FLAG_SECURE in WindowManager.LayoutParams for more information.

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) attacks typically involve an attempt to trick a logged-in user to click on a malicious URL on a vulnerable site in order to gain access to the user's account. These attacks often use a browser exploit that allows the attacker to add a session cookie to the request.

By design, native mobile apps are not as vulnerable to CSRF attacks as web apps. This is because any malicious URL that the user clicks on opens in the mobile device's default browser which does not share the cookie jar with the native app.

If you want to use Cross-Site Request Forgery (CSRF) protection for your application, first you must enable this feature in the mobile services cockpit. See Defining Application Security for more information.

Once CSRF is enabled, you must then construct network requests to handle this. See Cross-Site Request Forgery Protection for more information.

Data Protection Regulations

Data protection is associated with numerous legal requirements and privacy concerns. In addition to compliance with general data privacy acts, you must consider compliance with industry-specific legislation in different countries.

This guide does not give any advice on whether these features and functions are the best method to support company, industry, regional, or country-specific requirements. Furthermore, it does not give any advice or recommendations with regard to additional features that would be required in a particular environment. Decisions related to data protection must be made on a case-by-case basis and under consideration of the given system landscape and the applicable legal requirements.

The General Data Protection Regulations (GDPR) is a new EU data protection law that came into effect in May 2018. The following are some sections of this law that you may want to consider:

  • SEC-224 - Capture explicit user consent before collecting any personal data non-interactively.
  • SEC-254 - Do not log sensitive personal data.
  • SEC-255 - Provide a report or display function which can be used to inform the data subjects about the personal data stored about them
  • SEC-256 - Erase personal data when all applicable retention periods have expired