Securing Applications

This document describes how to design data management applications for data security. It explains the capabilities to track and avoid data breaches in the applications.

HTTP Security

There are several security aspects to bear in mind with applications:

  • Securing Communication: The browser and the Semarchy xDM server exchange information, which includes the data that is displayed in the application. This information is transferred over the HTTP protocol, which is not encrypted by default. We strongly recommend configuring the application server hosting Semarchy xDM to serve all its resources over the HTTP/S protocol.

  • Cross-Origin Resource Sharing (CORS) is a mechanism used to let other applications access resources from Semarchy xDM applications. By default, Semarchy xDM (both the applications and the REST APIs) are configured to refuse cross-origin requests. Administrators may use the corsAllowOrigins system property to declare trusted server with which CORS is enabled. For example, use -DcorsAllowOrigins= to allow this server to access resources in Semarchy xDM applications.

  • Embedding consists in rendering applications within another page (in an <iframe>, for example), with risks of clickjacking. Semarchy xDM applications by default only support embedding in applications served from the same server as the applications, using the X-Frame-Options:SAMEORIGIN HTTP header. Administrators may use the com.semarchy.mdm.xframeoptions system property to configure a different value for this header. For example -Dcom.semarchy.mdm.xframeoptions=allow-from to allow embedding application into pages served from this server.

  • Measures against cross-site scripting (XSS), content sniffing, click-jacking should be enabled at the application server level. For example, by configuring Tomcat’s HTTP header security filter. Similarly, setting up IP address filtering and restriction is a good practice when the application is visible on the Internet.

  • The application server may use cookies that contain sensitive data (e.g. session identifiers). These cookies can be stolen:

    • Via XSS attacks if made available to JavaScript code. To prevent this, HttpOnly should be set in the Set-Cookie HTTP response header. For example, using the useHttpOnly property of the Context configuration in Apache Tomcat.

    • Via a man-in-the-middle attack. To prevent this, the Secure flag should be set in the Set-Cookie HTTP response header, to prevent cookies sent over unencrypted HTTP requests. For example, using the secure property in Tomcat’s HTTP Connector configuration. Note that this requires setting up secured communications with HTTP/S.

Secured Application Design

Data management applications run in a web browser and display pages generated with the elements of the model (forms, collections) combined with data from the records stored in the hub.

In Semarchy xDM applications, three types of form/collection field types allow script execution: Markdown, Hyperlink, and Object.

These fields allow the designer to run scripts in collections and forms, in order to enhance the user experience. The model designer is always considered a trusted source from the point of view of the application security, and he is allowed to insert scripts within the forms and collections.

These fields can also display data entered or imported by end-users or integrated from external sources. They can also display this data combined with designer scripts. For example, to display an access map using Google Map, the designer may use a script into which he uses an address entered by a user. There is a possibility for an attacker to inject a script or to refer to external scripts within the data to perform silent operations with the connected user credentials.

For example, if using a Markdown field to display rich text content entered by users, nothing prevents a user from entering HTML content, including <script> tags with code using the internal communication API between the web browser and the Semarchy xDM server to insert, update or delete data records. This script would run within the web browser with the credential of the user connected to Semarchy xDM.

To prevent such attacks, designers should use with extreme caution these fields, preferably rendering only information from trusted sources, and if possible sanitizing the data using SemQL enrichers and validations. For example, using SemQL validation to reject values containing the "<script>" tag.