• Protection contre les attaques SSJS (Server Side JS Injection)
• Protection contre les attaques CSRF (Cross-Site Request Forgery)
• Protection contre les attaques XSS (Cross Site Scripting)
• Accès à la console d’administration H2 (base de données DDAudit et commentaires)
• Protection contre les attaques "Path Traversal"
• Protection contre les attaques XXE (XML External Entity)
• Chiffrement du mot de passe envoyé lors de l'authentification
• Chiffrement des cubes sur le disque
  • Stockage de clés

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 ».

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 :

• Pour utiliser certaines fonctionnalités d’administrations ou de consultation en dehors des pages prévues à cet effet
• Pour utiliser des objets Java custom dans le cadre de mesures dérivées
• Intégrer de manière très poussée des pages de tableau de bord dans un portail existant.

Ce chapitre liste les propriétés permettant de configurer ou désactiver ces protections.

Tous les paramètres sont à saisir dans le fichier system.xml.

Exemple de syntaxe XML :

Protection contre les attaques SSJS (Server Side JS Injection)

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.

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.

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.

Si besoin on pourra ajouter des classes Java à cette liste en utilisant le paramètre :

• Nom : PROP_JS_SANDBOX_CLASSES
  Valeur : Chaîne (défaut : vide)
  Description : Noms de classe java séparés par des virgules (ex : mon.package.MaClasse)

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 :

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 :

• Nom : PROP_JS_SANDBOX_TIMEOUT
  Valeur : Entier positif (millisecondes, défaut : 0 = aucun)
  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)
• Nom : PROP_JS_SANDBOX_TIMEOUT_EXPORT
  Valeur : Entier positif (millisecondes, défaut : 0 = aucun)
  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)

Débogage

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 ».

Protection contre les attaques CSRF (Cross-Site Request Forgery)

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 :

1. Vérification d’entête HTTP et de token aléatoire :
   • 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).
   • Pour les opérations effectuées via appel « Ajax » ou via une application cliente DigDash (Tableau de bord, Studio, application custom...), 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.
     Note : Une application custom peut utiliser le header HTTP "X-Requested-With" avec la valeur "DigDash Enterprise Client" pour satisfaire la contrainte de protection contre CSRF et permettre l'appel d'APIs en direct depuis une application externe, par exemple un script curl.
2. 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).

Les paramètres suivants permettent de désactiver complètement ou partiellement cette protection :

• Nom : PROP_CSRF_CHECK
  Valeur : Booléen (défaut : true)
  Description : Définit l’activation ou non de la protection CSRF. 
• Nom : PROP_CSRF_CHECK_ORIGIN
  Valeur : Booléen (défaut : true)
  Description : Définit l’activation ou non de la vérification de l’origine de la requête HTTP.
• Nom : PROP_CSRF_CHECK_TOKEN
  Valeur : Booléen (défaut : true)
  Description : Définit l’activation ou non de la vérification d’un token aléatoire obligatoire pour les opérations d’administration.
• Nom : PROP_CSRF_CHECK_XHR
  Valeur : Booléen (défaut : true)
  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).
• Nom : PROP_CSRF_PUNISH
  Valeur : Booléen (défaut : false)
  Description : true : La session à l'origine de l'attaque est déconnectée.

Débogage

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 »).

Protection contre les attaques XSS (Cross Site Scripting)

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é.

Les paramètres suivants permettent de désactiver complètement ou partiellement cette protection :

• Nom : PROP_XSS_CHECK
  Valeur : Booléen (défaut : true)
  Description : Définit l’activation ou non de la protection XSS. 
• Nom : PROP_XSS_PUNISH
  Valeur : Booléen (défaut : false)
  Description : true : La session à l'origine de l'attaque est déconnectée.
• Nom : PROP_XSS_CHECKIMAGE
  Valeur : Booléen (défaut : true)
  Description : true : Les upload d'images SVG pouvant contenir du code JS sont vérifiées.

Débogage

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 / Sécurité (événement « HackAttempt »).

Accès à la console d’administration H2 (base de données DDAudit et commentaires)

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.

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.

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 :

Protection contre les attaques "Path Traversal"

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é.

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 :

• Nom : PROP_PATH_PUNISH
  Valeur : Booléen (défaut : false)
  Description : true : La session à l'origine de l'attaque est déconnectée.

Débogage

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 »).

Protection contre les attaques XXE (XML External Entity)

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.

Le paramètre suivant permettent de désactiver cette protection :

• Nom : PROP_XXE_PROTECTION
  Valeur : Booléen (défaut : true)
  Description : Définit l’activation ou non de la protection XXE. 

Chiffrement du mot de passe envoyé lors de l'authentification

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.

Le paramètre suivant permettent de configurer cette protection :

• Nom : PROP_CRYPTPASS
  Valeur : Chaîne allow, force ou <vide> (défaut : <vide>)
  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.

Chiffrement des cubes sur le disque

DigDash Enterprise permet de chiffrer les fichiers des cubes. Dans le cas où les fichiers de cubes sont subtilisés, ils ne seraient pas exploitables sans disposer de la clé de déchiffrement. Par défaut cette option n'est pas active.

Pour l'activer il faut ajouter le paramétrage suivant :

• Nom : CRYPT_CUBES
  Valeur : Booléen (défaut : false)
  Description : true : le chiffrement des cubes est activé.
• Nom : CRYPT_CUBES_PASS (optionnel)
  Valeur : Chaîne (défaut : <vide / non défini>)
  Description :
  • <vide / non défini> : la clé de chiffrement est générée aléatoirement au premier démarrage d'un déploiement DigDash. La clé générée est stockée dans un fichier de clés global à DigDash Enterprise (voir paragraphe suivant).
  • <non vide> : la chaîne sera utilisée pour générer la clé cryptographique au démarrage du serveur (clé non stockée).

Stockage de clés

Selon les options de chiffrement, des clés doivent être enregistrées dans un fichier de stockage de clés ("keystore") sécurisé au format pkcs12. Le paramétrage suivant permet de spécifier l'emplacement de ce fichier :

• Nom : digdash.keystore (à définir dans le fichier digdash.properties)
  Valeur : Chemin de fichier (défaut : <vide>)
  Description :
  • <vide / non défini> : le fichier par défaut est ddkeys.pkcs12, créé dans le répertoire de travail de Tomcat si besoin.
  • <Chemin de fichier> : le chemin spécifié sera utilisé. Le fichier doit porter l'extension pkcs12. Il est conseillé de spécifier un chemin vers un dossier sécurisé, différent du dossier où les cubes sont situés. Note : le fichier de stockage de clés n'est pas inclus dans le backup DigDash Enterprise.