Last modified by Aurelie Bertrand on 2026/01/12 16:46
Show last authors
1 {{ddtoc/}}
2
3 ----
4
5 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".
6
7 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 :
8
9 * To use certain administration or consultation functions outside the pages provided for this purpose
10 * To use custom Java objects as part of derivative measures
11 * To integrate dashboard pages into an existing portal.
12
13 This chapter lists the properties that can be used to configure or deactivate these protections.
14
15 All the parameters must be entered in the **system.xml** file.
16
17 Example of XML syntax :
18
19 {{code cssClass="notranslate"}}
20 <Property key="PROP_..." value="12345"></Property>
21 {{/code}}
22
23 = Protection against SSJS (Server Side JS Injection) attacks =
24
25 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.
26
27 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.
28
29 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.
30
31 If required, Java classes can be added to this list using the :
32
33 * //Name//: **PROP_JS_SANDBOX_CLASSES**
34 //Value//: String (default: empty)
35 //Description//: Java class names separated by commas (e.g. my.package.MyClass)
36
37 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:
38
39 {{code language="javascript" cssClass="notranslate"}}
40 while(true){};return 0;
41 {{/code}}
42
43 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:
44
45 * //Name//: **PROP_JS_SANDBOX_TIMEOUT**
46 //Value//: Positive integer (milliseconds, default: 0 = none)
47 //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).
48 * //Name//: **PROP_JS_SANDBOX_TIMEOUT_EXPORT**
49 //Value//: Positive integer (milliseconds, default: 0 = none)
50 //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).
51
52 **Debugging**
53
54 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".
55
56 = Protection against CSRF (Cross-Site Request Forgery) attacks =
57
58 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:
59
60 1. HTTP header and random token checking:
61 1*. **For administration operations, a random token associated with the current session must necessarily be sent by the administration page on each form submission (CSRFToken).**
62 1*. 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.
63 //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.//
64 1. 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).
65
66 The following parameters can be used to completely or partially disable this protection:
67
68 * //Name//: **PROP_CSRF_CHECK**
69 //Value//: Boolean (default: true)
70 //Description//: Defines whether or not to enable CSRF protection.
71 * //Name//: **PROP_CSRF_CHECK_ORIGIN**
72 //Value//: Boolean (default: true)
73 //Description//: Defines whether or not to enable verification of the origin of the HTTP request.
74 * //Name//: **PROP_CSRF_CHECK_TOKEN**
75 //Value//: Boolean (default: true)
76 //Description//: Defines whether or not to enable the verification of a random token which is mandatory for administration operations.
77 * //Name//: **PROP_CSRF_CHECK_XHR**
78 //Value//: Boolean (default: true)
79 //Description//: Defines whether or not to enable checking of the value of a specific HTTP header for calls via a DigDash client (Dashboard, Studio).
80 * //Name//: **PROP_CSRF_PUNISH**
81 //Value//: Boolean (default: false)
82 //Description//: true: The session at the origin of the attack is disconnected.
83
84 **Debugging**
85
86 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).
87
88 = Protection against XSS (Cross Site Scripting) attacks =
89
90 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.
91
92 The following parameters can be used to completely or partially disable this protection:
93
94 * //Name//: **PROP_XSS_CHECK**
95 //Value//: Boolean (default: true)
96 //Description//: Defines whether or not XSS protection is enabled.
97 * //Name//: **PROP_XSS_PUNISH**
98 //Value//: Boolean (default: false)
99 //Description//: **true **: The session at the origin of the attack is disconnected.
100 * //Name//: **PROP_XSS_CHECKIMAGE**
101 //Value//: Boolean (default: true)
102 //Description//: **true **: SVG image uploads that may contain JS code are checked.
103
104 **Debugging**
105
106 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).
107
108 = Access to the H2 administration console (DDAudit database and comments) =
109
110 DigDash Enterprise uses the H2 database internally to store DDAudit information and user comments on dashboards.
111
112 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.
113
114 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:
115
116 {{code language="xml" cssClass="notranslate"}}
117 <!--
118 Due to a security issue with H2 console third party we are desactivating it by default.
119 If you intend to use this option, it is recommended to:
120 - change the default sa password for H2
121 - change the password used in DDAudit module's datasources
122 - make sure the URL is not publicly available on Internet
123 - uncomment the following block
124 -->
125 <!--
126 <servlet>
127 <servlet-name>H2Console</servlet-name>
128 <servlet-class>org.h2.server.web.WebServlet</servlet-class>
129 <init-param>
130 <param-name>webAllowOthers</param-name>
131 <param-value>1</param-value>
132 </init-param>
133 <load-on-startup>1</load-on-startup>
134 </servlet>
135 <servlet-mapping>
136 <servlet-name>H2Console</servlet-name>
137 <url-pattern>/ddh2console/*</url-pattern>
138 </servlet-mapping>
139 <servlet-mapping>
140 <servlet-name>H2Console</servlet-name>
141 <url-pattern>/ddh2console</url-pattern>
142 </servlet-mapping>
143 -->
144 {{/code}}
145
146 (% class="box errormessage" %)
147 (((
148 Important: It is strongly advised in this case to change the default password, and to restrict access to this console to a subset of the network, for example using firewall or routing rules.
149
150 The password is defined in this same file via the **comment.db.password** and **audit.db.password** parameters. Note that for DDAudit you will also need to update the password in the data models and the connection named **DDAudit**.
151 )))
152
153 = Protection against path traversal attacks =
154
155 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.
156
157 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:
158
159 * //Name//: **PROP_PATH_PUNISH**
160 //Value//: Boolean (default: false)
161 //Description//: **true **: The session at the origin of the attack is disconnected.
162
163 **Debugging**
164
165 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).
166
167 = Protection against XXE (XML External Entity) attacks =
168
169 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.
170
171 The following parameter can be used to disable this protection:
172
173 * //Name//: **PROP_XXE_PROTECTION**
174 //Value//: Boolean (default: true)
175 //Description//: Defines whether or not XXE protection is enabled.
176
177 = Encryption of the password sent during authentication =
178
179 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.
180
181 The following parameters are used to configure this protection:
182
183 * //Name//: **PROP_CRYPTPASS**
184 //Value//: Allow, force or <empty> string (default: <empty>)
185 //Description//: **<empty> **: protection is not enabled. **allow **: encryption is possible for a client (but not mandatory), **force **: encryption is mandatory.
186
187 = Encrypting cubes on disk =
188
189 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.
190
191 (% class="box infomessage" %)
192 (((
193 This option affects writing performance and the initial loading of cubes.
194 )))
195
196 To activate it, the following parameter must be added:
197
198 * //Name//: **CRYPT_CUBES**
199 //Value//: Boolean (default: false)
200 //Description//: **true **: cube encryption is enabled.
201 * //Name//: **CRYPT_CUBES_PASS** (optional)
202 //Value//: String (default: <empty / undefined>)
203 //Description//:
204 ** **<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).
205 ** **<not empty>**: the string will be used to generate the cryptographic key at server startup (key not stored).
206
207 == Key storage ==
208
209 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:
210
211 * //Name//: **digdash.keystore** (to be defined in the **digdash.properties** file)
212 //Value//: File path (default: <empty>)
213 //Description//:
214 ** **<empty/undefined> **: the default file is ddkeys.pkcs12, created in Tomcat's working directory if required.
215 ** **<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.