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.
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
corsAllowOriginssystem property to declare trusted server with which CORS is enabled. For example, use
-DcorsAllowOrigins=http://example.acme.comto 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:SAMEORIGINHTTP header. Administrators may use the
com.semarchy.mdm.xframeoptionssystem property to configure a different value for this header. For example
-Dcom.semarchy.mdm.xframeoptions=allow-from https://example.acme.com/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.
HttpOnlyshould be set in the
Set-CookieHTTP response header. For example, using the
useHttpOnlyproperty of the Context configuration in Apache Tomcat.
Via a man-in-the-middle attack. To prevent this, the
Secureflag should be set in the
Set-CookieHTTP response header, to prevent cookies sent over unencrypted HTTP requests. For example, using the
secureproperty 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.