• Protection against SSJS (Server Side JS Injection) attacks
• Protection against CSRF (Cross-Site Request Forgery) attacks
• Protection against XSS (Cross Site Scripting) attacks
• Access to the H2 administration console (DDAudit database and comments)
• Protection against path traversal attacks
• Protection against XXE (XML External Entity) attacks
• Encryption of the password sent during authentication
• Encrypting cubes on disk
  • Key storage

DigDash Enterprise incorporates various protection mechanisms to counter attacks such as "server code injection" (e.g. SSJS: Server Side JS Injection), "cross-site scripting" (XSS), "cross-site request forgery" (CSRF) and "directory/path traversal".

These mechanisms are active by default. In certain rare cases (and in controlled environments), it may be necessary to completely or partially disable some of these protections, for example :

• To use certain administration or consultation functions outside the pages provided for this purpose
• To use custom Java objects as part of derivative measures
• To integrate dashboard pages into an existing portal.

This chapter lists the properties that can be used to configure or deactivate these protections.

All the parameters must be entered in the system.xml file.

Example of XML syntax :

Protection against SSJS (Server Side JS Injection) attacks

DigDash Enterprise uses Javascript for a number of tasks. Javascript used on the browser side does not generally pose any security problems (specific to DigDash). On the other hand, Javascript evaluated on the server side does pose a risk. This is the case for derived measures, formulas for ad-hoc analysis (Self Service BI), hierarchy formulas, filters, etc. These elements are evaluated on the server side using a Javascript interpreter run by the Java virtual machine.

In DigDash Enterprise we have protected this interpreter against access to objects in the Java virtual machine that are not necessary for it to function properly. For example, a derived measure never needs to access the server's file system, or launch an executable on the server.

Java classes accessible via Javascript code are listed on the "white list" principle to enable DigDash Enterprise to evaluate legitimate scripts. However, any call to an unlisted object within a malicious function will be traced in the logs and will cause an error.

If required, Java classes can be added to this list using the :

• Name: PROP_JS_SANDBOX_CLASSES
  Value: String (default: empty)
  Description: Java class names separated by commas (e.g. my.package.MyClass)

Another type of attack is the DOS ("Denial-Of-Service") attack, which consists of rendering the system inoperable. For example, an SSJS/DOS attack would be to enter a formula:

This formula causes the Javascript interpreter to loop infinitely. We also have protection for this type of attack, but for optimisation reasons it is not activated by default. To activate it, you need to create the following parameters:

• Name: PROP_JS_SANDBOX_TIMEOUT
  Value: Positive integer (milliseconds, default: 0 = none)
  Description: Maximum evaluation time of the JS formula in milliseconds. Unless you have a really complex formula, this type of time should not exceed one second (1000).
• Name: PROP_JS_SANDBOX_TIMEOUT_EXPORT
  Value: Positive integer (milliseconds, default: 0 = none)
  Description: Maximum evaluation time of a table-type Flow export in PDF, PPT, Excel (with styles) in milliseconds. In this case the time can be quite long, depending on the size of the table, several tens of seconds, for example one minute (60000).

Debugging

Errors linked to SSJS protection are logged with the prefix "SSJS Protection" and an explanation of the source of the error. Errors related to execution times that are too long are generally logged as a "ScriptTooLongError".

Protection against CSRF (Cross-Site Request Forgery) attacks

We will not describe this complex type of attack in this chapter, as it is well documented on the Internet. DigDash Enterprise provides protection against CSRF attacks at two levels:

1. HTTP header and random token checking:
   • For administration operations, a random token associated with the current session must necessarily be sent by the administration page on each form submission (CSRFToken).
   • For operations carried out via an "Ajax" call or via a DigDash client application (Dashboard, Studio, custom application, etc.), we check for an HTTP header added during legitimate calls. It is a priori impossible for a CSRF attack to specify additional HTTP headers.
     Note: A custom application can use the HTTP header "X-Requested-With" with the value "DigDash Enterprise Client" to satisfy the CSRF protection constraint and allow APIs to be called directly from an external application, for example a curl script.
2. For each incoming HTTP request we check the source of the request, which must be identical to the source of the request that authenticated the current session (identical origin principle).

The following parameters can be used to completely or partially disable this protection:

• Name: PROP_CSRF_CHECK
  Value: Boolean (default: true)
  Description: Defines whether or not to enable CSRF protection.
• Name: PROP_CSRF_CHECK_ORIGIN
  Value: Boolean (default: true)
  Description: Defines whether or not to enable verification of the origin of the HTTP request.
• Name: PROP_CSRF_CHECK_TOKEN
  Value: Boolean (default: true)
  Description: Defines whether or not to enable the verification of a random token which is mandatory for administration operations.
• Name: PROP_CSRF_CHECK_XHR
  Value: Boolean (default: true)
  Description: Defines whether or not to enable checking of the value of a specific HTTP header for calls via a DigDash client (Dashboard, Studio).
• Name: PROP_CSRF_PUNISH
  Value: Boolean (default: false)
  Description: true: The session at the origin of the attack is disconnected.

Debugging

Errors relating to CSRF protection are logged with the prefix "CSRF Protection" and an explanation of the source of the error. These errors are also added to DDAudit / Security ("HackAttempt" event).

Protection against XSS (Cross Site Scripting) attacks

An XSS attack is carried out by manipulating a request parameter and injecting a script that could be executed by another user. Protection against XSS attacks checks all request parameters arriving at the DigDash server and is triggered when an inappropriate script is detected.

The following parameters can be used to completely or partially disable this protection:

• Name: PROP_XSS_CHECK
  Value: Boolean (default: true)
  Description: Defines whether or not XSS protection is enabled.
• Name: PROP_XSS_PUNISH
  Value: Boolean (default: false)
  Description: true : The session at the origin of the attack is disconnected.
• Name: PROP_XSS_CHECKIMAGE
  Value: Boolean (default: true)
  Description: true : SVG image uploads that may contain JS code are checked.

Debugging

Errors relating to XSS protection are logged with the prefix "XSS Protection" and an explanation of the source of the error. These errors are also added to DDAudit / Security ("HackAttempt" event).

Access to the H2 administration console (DDAudit database and comments)

DigDash Enterprise uses the H2 database internally to store DDAudit information and user comments on dashboards.

Following the discovery of a security vulnerability in the H2 administration console, which has not yet been corrected by the community, we have decided to remove access to this console (/ddenterpriseapi/ddh2console) by default.

To use this H2 database administration tool again, you will need to reactivate the ddh2console console. This is done by removing the comment markers around <servlet> in the following XML extract from the ddenterpriseapi web.xml file:

Protection against path traversal attacks

A "Path Traversal" attack is carried out by manipulating a parameter of a request to download a data source file (from a document server) in order to modify its path and attempt to retrieve a system file from the server. To prevent this type of attack DigDash Enterprise prohibits the downloading of files located outside the specified document server.

This protection cannot be disabled, but the following parameter can be used to configure the behaviour to adopt in the event of this type of attack:

• Name: PROP_PATH_PUNISH
  Value: Boolean (default: false)
  Description: true : The session at the origin of the attack is disconnected.

Debugging

Errors relating to "Path Traversal" protection are logged with the prefix "Path Traversal Protection" and an explanation of the source of the error. These errors are also added to DDAudit / Security ("HackAttempt" event).

Protection against XXE (XML External Entity) attacks

An XXE attack uses an XML file formed specifically to call an external XML entity resolution resource, or a DTD, or an XML schema. If the file is interpreted on the server side, the server could send useful information to an attacker, such as the attacker's address, and/or allow the attacker to inject information back into the XML file. For example, a large volume that could compromise the stability of the server (DOS-type attack). To prevent this attack, DigDash Enterprise disables by default the processing of any external entity/resource in the XML files it has to interpret.

The following parameter can be used to disable this protection:

• Name: PROP_XXE_PROTECTION
  Value: Boolean (default: true)
  Description: Defines whether or not XXE protection is enabled.

Encryption of the password sent during authentication

DigDash Enterprise can encrypt the password sent during user authentication, to minimise the risk of interception when the network is compromised (e.g. "Man In The Middle" attack). Encryption uses a public/private key pair that allows a client to encrypt the password that only the server can decrypt.

The following parameters are used to configure this protection:

• Name: PROP_CRYPTPASS
  Value: Allow, force or <empty> string (default: <empty>)
  Description: <empty> : protection is not enabled. allow : encryption is possible for a client (but not mandatory), force : encryption is mandatory.

Encrypting cubes on disk

DigDash Enterprise can encrypt cube files. If the cube files are stolen, they cannot be used without the decryption key. This option is not active by default.

To activate it, the following parameter must be added:

• Name: CRYPT_CUBES
  Value: Boolean (default: false)
  Description: true : cube encryption is enabled.
• Name: CRYPT_CUBES_PASS (optional)
  Value: String (default: <empty / undefined>)
  Description:
  • <empty / undefined> : the encryption key is randomly generated when a DigDash deployment is first started. The generated key is stored in a DigDash Enterprise global key file (see next paragraph).
  • <not empty>: the string will be used to generate the cryptographic key at server startup (key not stored).

Key storage

Depending on the encryption options, keys must be stored in a secure key storage file ("keystore") in pkcs12 format. The following settings are used to specify the location of this file:

• Name: digdash.keystore (to be defined in the digdash.properties file)
  Value: File path (default: <empty>)
  Description:
  • <empty/undefined> : the default file is ddkeys.pkcs12, created in Tomcat's working directory if required.
  • <File path>: the specified path will be used. The file must have the extension pkcs12. It is advisable to specify a path to a secure folder, different from the folder where the cubes are located. Note: the key storage file is not included in the DigDash Enterprise backup.