Security

The ownCloud iOS SDK (2018) is a general-purpose API for implementing passphrase- and token-based authentication methods, which provides three key benefits. These are:

Authentication secrets contain information such as usernames, passwords or tokens, and are generated by the respective authentication method implementation. Authentication Secrets are securely stored in the app’s Keychain and tagged as AccessibleAfterFirstUnlock. They cannot be accessed after a restart until the device has been unlocked once by the user.

Authentication method implementations are available for OAuth2 and Basic Authentication.

After performing auto-detection, identified authentication methods are filtered and ranked by preference. The method with the highest ranking is then picked for the user.

Filtering and ranking can be customized by MDM Configuration. This, for example, allows making OAuth2 the only possible authentication method, so no credentials need to be stored on the device.

The OAuth2 implementation uses SFAuthenticationSession, which is described as a best practice by RFC 8252 - when running under iOS 11. Under iOS 12, the OAuth2 implementation uses ASWebAuthenticationSession, which is the successor of SFAuthenticationSession. Benefits of using these APIs include:

Using MDM Configuration, server URLs can be pre-filled or "hard-coded" as the only allowed server URL.

Redirects during login are not followed silently. Instead, they are reported to the user and must be explicitly approved.

When adding servers, users have the opportunity to view a detailed summary of the server’s SSL/TLS certificate before they are prompted for credentials or authentication via OAuth2.

If a SSL/TLS certificate fails trust evaluation (e.g., because it’s self-signed or signed by an unknown Certificate Authority), the user is given an opportunity to:

In the case of redirects across several HTTPS servers, users are given the opportunity to review the certificates of all servers involved in addition to the redirects.

If users want to inspect the details of an approved security certificate, from the Accounts list, swipe left on the account that you want to check the certificate of and click Edit. Then, click the row Certificate Details. You will then see the certificate’s details, starting with the validation status.

For more information, please refer to the security information.

Separate directories are used for the data of every server connection. This provides the following benefits:

The app uses the filesystem encryption built into iOS. Using the CompleteUntilFirstUserAuthentication file protection, data can’t be accessed after a restart until the device has been unlocked once by the user.

The Sync Strategies, planned to be used in the app, focus on preventing data loss locally and remotely.

HTML and Microsoft Office document content is viewed using WKWebView, which renders the content in a separate process. Additional hardening is achieved by disabling JavaScript and blocking all network requests, which protects against lesser known, non-obvious attacks like CSS Keylogging.

Users can set a Passcode to control access to the app. Find out more about this in the Passcode section of the Settings documentation.

Continuous Integration tests verify that central security mechanisms and assumptions work as expected, covering areas such as redirections, certificate handling, common Man-in-the-middle (MITM) attack scenarios, and the secure storage of authentication secrets.

To protect against SQL injection attacks, parameters are never made part of the SQL statements themselves. Instead, placeholders are used and the parameters are subsequently bound to the SQL statements. For example, instead of running a query, such as SELECT * FROM users WHERE name='John Doe', the query would be parameterised, such as: SELECT * FROM users WHERE name=:nameToSearchFor.

The build script that created the OpenSSL binaries used in the app is available in the SDK’s GitHub repository and can be used to reproduce the build result.

When logging information, parts of the log message can be tagged as private. If "Mask private data" is enabled, under Settings  Logging (it is by default), these parts will be - before the log message is written - either replaced with «private» or a trimmed version that doesn’t contain privacy-sensitive information.

An example for the latter would be an NSError object’s error message containing the names of the item it is about. If masked, only the error’s error domain and error code are written to the log, but not the error message.