App Suite Security

Sharing

Shares are accessed with a hyperlink that contains the so-called share "token". This 24-byte token uniquely identifies the associated guest account on the system using a version 4 UUID with randomly generated 122 Bit to obfuscate the account information.

Explicitly invited guest users receive this hyperlink in the invitation mail to a share, while in case of an "anonymous" share where just the link itself was generated, it's up to the sharing user to distribute the link on their own. Besides the token, a share link may contain an additional path that points to the concrete folder and item, which just aids to jump to the shared item in the web interface directly.

Authentication

OX App Suite offers three different authentication options for guest users accessing a share, each of them having their own characteristics.

Anonymous

Access is granted without providing additional authentication information, the knowledge of the link is sufficient. When accessing the share link, a guest session is spawned implicitly. Exiting cookies are considered to recycle an existing session. The login screen is skipped, we'll redirect to the module/folder/item directly (using appropriate URL fragments).

Anonymous with PIN

Access is granted for anonymous guest users providing a password / PIN code. When accessing the share link, the client is redirected to the login screen of the webinterface, using login_type=anonymous. User can then enter their PIN code, client executes the anonymous_login method, server authenticates, sends back a login response containing the target in the OX App Suite web interface (module/folder/item). The password can't be changed by an anonymous user, it can be re-constructed or changed by sharing user.

Guest without Password

Access is granted without providing additional authentication information, the knowledge of the guest's individual link is sufficient. When accessing the share link, a guest session is spawned implicitly. Exiting cookies are considered to recycle an existing session. The login screen is skipped and redirect to the module/folder/item directly (using appropriate URL fragments). Guest user may choose an individual password at a later stage.

Guest with Password

Access is granted for guest users providing a user name and password. Much similar to a regular user. When accessing the share link, the client is redirected to the login screen of the webinterface, using login_type=guest and login_name=NAME. The login name is used to pre-fill the username input. User can then enter their password, client executes the guest_login method, server authenticates, sends back a login response containing the target in the app suite webinterface (module/folder/item). The password can be changed by guest user. Guest user may reset their password if they can't remember.

Cookies

Guest sessions make use of the same cookies as regular user sessions do. This includes the JSESSONID cookie for the JVM route, as well as the open-xchange-secret- and open-xchange-public-session- cookies. The cookie hashes are calculated in a way that also the guest user context- and user identifiers are taken into account. Doing so, this allows to use the regular user session as well as one or more guest sessions from within the same client - e.g. if the sharing user wants to check how the contents appear for the guest user after generating a share link.

Additionally, if configured, the client may also issue a store request to persist the open-xchange-session- cookie. This cookie may then be used to auto-login the guest client into the previously used session if it is still valid.

Potential Security Risks

Customer generated content

Attachments and the "sharing" capability enables ways to provide user-generated content, which opens up the possibility to exploit the platform as a trusted source for malware distribution. This could be done by registering as a seemingly legitimate user, compromising existing users accounts or provide content through external communication channels, like E-Mail.

OX App Suite implements hooks to invoke external malware scanning applications when downloading Mail, PIM attachments or Drive items. Operators are able to define a specific malware scanner that performs the actual analysis using ICAP. Based on the result of this analysis, OX App Suite will either pass the download or ask the user how to proceed in case potential malware has been detected, or the requested file could not be scanned due to size limitations.

The implementation of shared files allows scenarios where a file is automatically offered for download via the API without explicitly triggering the download. When having malware scanning enabled and a positive match occurs, an error message instead of the requested file will not be provided. Mind that this mechanism has its limitations regarding fragments of script code and depends on a recent malware identification database.

Content delivery

By default, OX App Suite delivers content and access to shares using the same domain as for "general" access to OX App Suite. This circumvents protection mechanisms like same-origin or content-security policies. It allows attackers to embed "raw" script code to HTML files that are shared and bypass existing sanitizers since the "bad code" is constructed by the browser rather than OX App Suite. It is possible to have guest shares being served from a different domain using the com.openexchange.share.guestHostname configuration parameter, which serves two purposes:

  • Allows same-origin or content-security policies to function, since the content is in a different domain
  • Prevents malicious content that is shared from the guest domain from "polluting" the domain used for general access to OX App Suite (for example through domain deny-listing).

Injected customer content

Sharing (as well as OX Guard) make use of "on-behalf-of" emails such as "User X shared something with you" which are sent using a system-mail account. However, these emails are not entirely system generated, as OX App Suite allows users to embed comments and even HTML content there.

Users may rate them as trustworthy because they are generated by the system. Bad actors may use techniques such as embedding some malicious content in those emails as a potential phishing mechanism.