Wiki source code of Réglages de sécurité avancés

Last modified by Aurelie Bertrand on 2026/01/12 16:46

version	line-number	content
4.1	1	{{ddtoc/}}
	2
	3	----
	4
21.1	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".
2.1	6
21.1	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 :
2.1	8
21.1	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.
2.1	12
21.1	13	This chapter lists the properties that can be used to configure or deactivate these protections.
2.1	14
21.1	15	All the parameters must be entered in the system.xml file.
2.1	16
21.1	17	Example of XML syntax :
2.1	18
16.1	19	{{code cssClass="notranslate"}}
12.1	20	<Property key="PROP_..." value="12345"></Property>
	21	{{/code}}
11.1	22
21.1	23	= Protection against SSJS (Server Side JS Injection) attacks =
2.1	24
21.1	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.
2.1	26
21.1	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.
2.1	28
21.1	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.
2.1	30
21.1	31	If required, Java classes can be added to this list using the :
2.1	32
21.1	33	* //Name//: PROP_JS_SANDBOX_CLASSES
	34	//Value//: String (default: empty)
	35	//Description//: Java class names separated by commas (e.g. my.package.MyClass)
2.1	36
21.1	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:
14.1	38
16.1	39	{{code language="javascript" cssClass="notranslate"}}
13.1	40	while(true){};return 0;
	41	{{/code}}
2.1	42
21.1	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:
2.1	44
21.1	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).
2.1	51
21.1	52	Debugging
2.1	53
21.1	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".
2.1	55
21.1	56	= Protection against CSRF (Cross-Site Request Forgery) attacks =
2.1	57
21.1	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:
2.1	59
21.1	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).
2.1	65
21.1	66	The following parameters can be used to completely or partially disable this protection:
2.1	67
21.1	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.
2.1	83
21.1	84	Debugging
2.1	85
21.1	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).
2.1	87
21.1	88	= Protection against XSS (Cross Site Scripting) attacks =
2.1	89
21.1	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.
2.1	91
21.1	92	The following parameters can be used to completely or partially disable this protection:
2.1	93
21.1	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.
2.1	103
21.1	104	Debugging
10.1	105
21.1	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).
10.1	107
21.1	108	= Access to the H2 administration console (DDAudit database and comments) =
2.1	109
21.1	110	DigDash Enterprise uses the H2 database internally to store DDAudit information and user comments on dashboards.
2.1	111
21.1	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.
2.1	113
21.1	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:
2.1	115
16.1	116	{{code language="xml" cssClass="notranslate"}}
2.1	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:
21.1	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
2.1	124	-->
	125	<!--
	126	<servlet>
21.1	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>
2.1	134	</servlet>
	135	<servlet-mapping>
21.1	136	<servlet-name>H2Console</servlet-name>
	137	<url-pattern>/ddh2console/*</url-pattern>
2.1	138	</servlet-mapping>
	139	<servlet-mapping>
21.1	140	<servlet-name>H2Console</servlet-name>
	141	<url-pattern>/ddh2console</url-pattern>
2.1	142	</servlet-mapping>
	143	-->
	144	{{/code}}
	145
	146	(% class="box errormessage" %)
	147	(((
21.1	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.
2.1	149
21.1	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.
2.1	151	)))
10.1	152
21.1	153	= Protection against path traversal attacks =
10.1	154
21.1	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.
10.1	156
21.1	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:
10.1	158
21.1	159	* //Name//: PROP_PATH_PUNISH
	160	//Value//: Boolean (default: false)
	161	//Description//: true : The session at the origin of the attack is disconnected.
10.1	162
21.1	163	Debugging
10.1	164
21.1	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).
10.1	166
21.1	167	= Protection against XXE (XML External Entity) attacks =
10.1	168
21.1	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.
10.1	170
21.1	171	The following parameter can be used to disable this protection:
10.1	172
21.1	173	* //Name//: PROP_XXE_PROTECTION
	174	//Value//: Boolean (default: true)
	175	//Description//: Defines whether or not XXE protection is enabled.
10.1	176
21.1	177	= Encryption of the password sent during authentication =
10.1	178
21.1	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.
10.1	180
21.1	181	The following parameters are used to configure this protection:
10.1	182
21.1	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.
16.4	186
21.1	187	= Encrypting cubes on disk =
16.4	188
21.1	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.
16.4	190
	191	(% class="box infomessage" %)
	192	(((
21.1	193	This option affects writing performance and the initial loading of cubes.
16.4	194	)))
	195
21.1	196	To activate it, the following parameter must be added:
16.4	197
21.1	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).
16.4	206
21.1	207	== Key storage ==
16.4	208
21.1	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:
16.4	210
21.1	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.

Wiki source code of Réglages de sécurité avancés

Sommaire