Last modified by jhurst on 2021/04/21 10:01
Show last authors
1 {{ddtoc/}}
2
3 ----
4
5 Différents mécanismes de protection sont intégrés à DigDash Enterprise pour contrer des attaques de type « injection de code serveur » (Ex. SSJS : Server Side JS Injection), « Cross-site scripting » (XSS), « Cross-Site Request Forgery » (CSRF) ou encore « Directory/Path traversal ».
6
7 Ces mécanismes sont actifs par défaut. Dans certains cas rares (et en environnement contrôlé), il peut être nécessaire de désactiver complètement ou partiellement certaines de ces protections, par exemple :
8
9 * Pour utiliser certaines fonctionnalités d’administrations ou de consultation en dehors des pages prévues à cet effet
10 * Pour utiliser des objets Java custom dans le cadre de mesures dérivées
11 * Intégrer de manière très poussée des pages de tableau de bord dans un portail existant.
12
13 Ce chapitre liste les propriétés permettant de configurer ou désactiver ces protections.
14
15 Tous les paramètres sont à saisir dans le fichier **system.xml**.
16
17 Exemple de syntaxe XML :
18
19 {{code}}
20 <Property key="PROP_..." value="12345"></Property>
21 {{/code}}
22
23
24 = Protection contre les attaques SSJS (Server Side JS Injection) =
25
26 DigDash Enterprise s’appuie sur l’utilisation du langage Javascript pour un certain nombre de taches. Le Javascript utilisé coté navigateur ne pose en général pas de problème de sécurité (spécifique à DigDash). Par contre le Javascript évalué coté serveur présente un risque. C’est le cas pour les mesures dérivées, les formules en analyse ad-hoc (Self Service BI), les formules de hiérarchies, de filtres, etc. Ces éléments sont évalués coté serveur à l’aide d’un interpréteur Javascript exécuté par la machine virtuelle Java.
27
28 Dans DigDash Enterprise nous avons protégé cet interpréteur contre l’accès à des objets de la machine virtuelle Java qui ne sont pas nécessaires à son bon fonctionnement. Par exemple une mesure dérivée n’a jamais besoin d’accéder au système de fichier du serveur, ou n’a jamais besoin de lancer un exécutable sur le serveur.
29
30 Les classes Java accessibles par du code Javascript sont listées sur le principe de « liste blanche » pour permettre à DigDash Enterprise d’évaluer les scripts légitimes. Par contre tout appel à un objet non listé au sein d’une fonction maligne sera tracé dans les logs et provoquera une erreur.
31
32 Si besoin on pourra ajouter des classes Java à cette liste en utilisant le paramètre :
33
34 * //Nom// : **PROP_JS_SANDBOX_CLASSES**
35 //Valeur// : Chaîne (défaut : vide)
36 //Description// : Noms de classe java séparés par des virgules (ex : mon.package.MaClasse)
37
38 Un autre type d’attaque est de type DOS (« Denial-Of-Service ») qui consiste à rendre le système inopérant. Par exemple une attaque SSJS/DOS sera de saisir une formule :
39
40 {{code language="javascript"}}
41 while(true){};return 0;
42 {{/code}}
43
44 Cette formule a pour effet de faire boucler de manière infinie l’interpréteur Javascript. Nous avons aussi une protection pour ce type d’attaque, mais pour des raisons d’optimisation elle n’est pas activée par défaut. Pour l’activer il faut créer les paramètres suivants :
45
46 * //Nom// : **PROP_JS_SANDBOX_TIMEOUT**
47 //Valeur// : Entier positif (millisecondes, défaut : 0 = aucun)
48 //Description// : Durée d’évaluation maximale de la formule JS en millisecondes. A moins d’une formule réellement très complexe ce genre de temps ne devrait pas excéder une seconde (1000)
49 * //Nom// : **PROP_JS_SANDBOX_TIMEOUT_EXPORT**
50 //Valeur// : Entier positif (millisecondes, défaut : 0 = aucun)
51 //Description// : Durée d’évaluation maximale d’un export de flux de type tableau en PDF, PPT, Excel (avec les styles) en millisecondes. Dans ce cas le temps peut-être assez long, en fonction de la taille du tableau, plusieurs dizaines de secondes,par exemple une minute (60000)
52
53 **Débogage**
54
55 Les erreurs liées à la protection SSJS sont tracées dans les logs avec le préfixe « SSJS Protection » et une explication de la source de l’erreur. Les erreurs liées à des temps d’exécution trop longs sont généralement tracés par une erreur de type « ScriptTooLongError ».
56
57 = Protection contre les attaques CSRF (Cross-Site Request Forgery) =
58
59 Nous ne décrirons pas ce type d’attaque complexe dans ce chapitre car ce sujet est largement documenté sur Internet. DigDash Enterprise fournit une protection contre les attaques CSRF à deux niveaux :
60
61 1. Vérification d’entête HTTP et de token aléatoire :
62
63 * **. Pour les opérations d’administration, un token aléatoire associé à la session courante doit nécessairement être envoyé par la page d’administration sur chaque soumission d’un formulaire (CSRFToken).**
64 ** Pour les opérations effectuées via appel « Ajax » ou via une application cliente DigDash (Tableau de bord, Studio), nous vérifions un entête HTTP ajouté lors des appels légitimes. Il est à priori impossible à une attaque CSRF de spécifier des entêtes HTTP additionnels.
65
66 1. A chaque requête HTTP entrante nous vérifions la source de la requête qui doit être identique à la source de la requête qui a authentifié la session courante (principe de l’origine identique).
67
68 Les paramètres suivants permettent de désactiver complètement ou partiellement cette protection :
69
70 * //Nom// : **PROP_CSRF_CHECK**
71 //Valeur// : Booléen (défaut : true)
72 //Description// : Définit l’activation ou non de la protection CSRF.
73 * //Nom// : **PROP_CSRF_CHECK_ORIGIN**
74 //Valeur// : Booléen (défaut : true)
75 //Description// : Définit l’activation ou non de la vérification de l’origine de la requête HTTP.
76 * //Nom// : **PROP_CSRF_CHECK_TOKEN**
77 //Valeur// : Booléen (défaut : true)
78 //Description// : Définit l’activation ou non de la vérification d’un token aléatoire obligatoire pour les opérations d’administration.
79 * //Nom// : **PROP_CSRF_CHECK_XHR**
80 //Valeur// : Booléen (défaut : true)
81 //Description// : Définit l’activation ou non de la vérification de la valeur d’un entête HTTP spécifique pour les appels via un client DigDash (Tableau de bord, Studio).
82 * //Nom// : **PROP_CSRF_PUNISH**
83 //Valeur// : Booléen (défaut : false)
84 //Description// : true : La session à l'origine de l'attaque est déconnectée.
85
86 **Débogage**
87
88 Les erreurs liées à la protection CSRF sont tracées dans les logs sous forme avec le préfixe « CSRF Protection » et une explication de la source de l’erreur. Ces erreurs sont également ajoutées à DDAudit / Securité (événement « HackAttempt »).
89
90 = Protection contre les attaques XSS (Cross Site Scripting) =
91
92 Une attaque de type XSS est faite en manipulant un paramètre d'une requête et en y injectant un script qui pourrait être exécuté par un autre utilisateur. Il y a une protection contre les attaques XSS qui vérifie tous les paramètres de requêtes arrivant dans le serveur DigDash et se déclenche lorsque q'un script inapproprié est détecté.
93
94 Les paramètres suivants permettent de désactiver complètement ou partiellement cette protection :
95
96 * //Nom// : **PROP_XSS_CHECK**
97 //Valeur// : Booléen (défaut : true)
98 //Description// : Définit l’activation ou non de la protection XSS.
99 * //Nom// : **PROP_XSS_PUNISH**
100 //Valeur// : Booléen (défaut : false)
101 //Description// : **true **: La session à l'origine de l'attaque est déconnectée.
102
103 **Débogage**
104
105 Les erreurs liées à la protection XSS sont tracées dans les logs sous forme avec le préfixe « XSS Protection » et une explication de la source de l’erreur. Ces erreurs sont également ajoutées à DDAudit / Securité (événement « HackAttempt »).
106
107 = Accès à la console d’administration H2 (base de données DDAudit et commentaires) =
108
109 DigDash Enterprise utilise de manière interne la base de données H2 pour stocker les informations de DDAudit et les commentaires des utilisateurs sur les tableaux de bord.
110
111 Suite à la découverte d’une faille de sécurité sur la console d’administration de H2, non corrigée à ce jour par la communauté, nous avons décidé de supprimer l’accès à cette console (/ddenterpriseapi/ddh2console) par défaut.
112
113 Pour bénéficier à nouveau de cet outil d’administration des bases H2, il vous faudra réactiver la console ddh2console. Cela se fait en supprimant les marqueurs de commentaires autour de **<servlet>** dans l’extrait XML suivant du fichier web.xml de ddenterpriseapi :
114
115 {{code language="xml"}}
116 <!--
117 Due to a security issue with H2 console third party we are desactivating it by default.
118 If you intend to use this option, it is recommended to:
119  - change the default sa password for H2
120  - change the password used in DDAudit module's datasources
121  - make sure the URL is not publicly available on Internet
122  - uncomment the following block
123 -->
124 <!--
125 <servlet>
126     <servlet-name>H2Console</servlet-name>
127     <servlet-class>org.h2.server.web.WebServlet</servlet-class>
128     <init-param>
129         <param-name>webAllowOthers</param-name>
130         <param-value>1</param-value>
131     </init-param>
132     <load-on-startup>1</load-on-startup>
133 </servlet>
134 <servlet-mapping>
135     <servlet-name>H2Console</servlet-name>
136     <url-pattern>/ddh2console/*</url-pattern>
137 </servlet-mapping>
138 <servlet-mapping>
139     <servlet-name>H2Console</servlet-name>
140     <url-pattern>/ddh2console</url-pattern>
141 </servlet-mapping>
142 -->
143 {{/code}}
144
145 (% class="box errormessage" %)
146 (((
147 Important : Il est fortement conseillé dans ce cas de changer le mot de passe par défaut, et de restreindre l’accès à cette console à un sous-ensemble du réseau, par exemple par des règles de pare-feu ou de routage.
148
149 Le mot de passe est définit dans ce même fichier via les paramètres **comment.db.password** et **audit.db.password**. Attention, pour DDAudit il faudra aussi mettre à jour le mot de passe dans les modèles de données.
150 )))
151
152 = Protection contre les attaques "Path Traversal" =
153
154 Une attaque de type "Path Traversal" est faite en manipulant un paramètre d'une requête de téléchargement d'un fichier de source de données (à partir d'un serveur de documents) pour en modifier son chemin et tenter de récupérer un fichier système du serveur. Pour prévenir ce genre d'attaque DigDash Enterprise interdit le téléchargement de fichiers situés en dehors du serveur de document spécifié.
155
156 Cette protection n'est pas désactivable mais le paramètre suivant permet de configurer le comportement à adopter lors d'une attaque de ce type :
157
158 * //Nom// : **PROP_PATH_PUNISH**
159 //Valeur// : Booléen (défaut : false)
160 //Description// : **true **: La session à l'origine de l'attaque est déconnectée.
161
162 **Débogage**
163
164 Les erreurs liées à la protection "Path Traversal" sont tracées dans les logs sous forme avec le préfixe « Path Traversal Protection » et une explication de la source de l’erreur. Ces erreurs sont également ajoutées à DDAudit / Securité (événement « HackAttempt »).
165
166 = Protection contre les attaques XXE (XML External Entity) =
167
168 Une attaque de type XXE utilise un fichier XML formé spécifiquement pour faire appel à une resource externe de résolution d'entité XML, ou une DTD, ou un schéma XML. Si le fichier est interprété coté serveur, ce dernier pourrait envoyer des informations utiles à un attaquant, telle que son adresse, et/ou permettre à l'attaquant d'injecter en retour des informations dans le fichier XML. Par exemple un grand volume qui pourrait compromettre la stabilité du serveur (attaque de type DOS). Pour prévenir cette attaque DigDash Enterprise désactive par défaut le traitement de toute entité/resource externe dans les fichiers XML qu'il doit interpréter.
169
170 Le paramètre suivant permettent de désactiver cette protection :
171
172 * //Nom// : **PROP_XXE_PROTECTION**
173 //Valeur// : Booléen (défaut : true)
174 //Description// : Définit l’activation ou non de la protection XXE.
175
176 = Chiffrement du mot de passe envoyé lors de l'authentification =
177
178 DigDash Enterprise permet de chiffrer le mot de passe envoyé lors de l'authentification d'un utilisateur, pour minimiser les risques d'interception lorsque le réseau est compromis (exemple de l'attaque "Man In The Middle"). Le chiffrement utilise une paire de clés publique/privée qui permet à un client de chiffrer le mot de passe que seul le serveur pourra déchiffrer.
179
180 Le paramètre suivant permettent de configurer cette protection :
181
182 * //Nom// : **PROP_CRYPTPASS**
183 //Valeur// : Chaîne allow, force ou <vide> (défaut : <vide>)
184 //Description// : **<vide>**: la protection n'est pas activée. **allow **: le chiffrement est possible pour un client (mais pas obligatoire), **force **: le chiffrement est obligatoire.