Réglages de sécurité avancés

Last modified by jhurst on 2022/04/28 16:42

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 :

<Property key="PROP_..." value="12345"></Property>

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 :

while(true){};return 0;

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

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.

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 / Securité (é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 :

<!--
Due to a security issue with H2 console third party we are desactivating it by default.
If you intend to use this option, it is recommended to:
 - change the default sa password for H2
 - change the password used in DDAudit module's datasources
 - make sure the URL is not publicly available on Internet
 - uncomment the following block
-->
<!--
<servlet>
    <servlet-name>H2Console</servlet-name>
    <servlet-class>org.h2.server.web.WebServlet</servlet-class>
    <init-param>
        <param-name>webAllowOthers</param-name>
        <param-value>1</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>H2Console</servlet-name>
    <url-pattern>/ddh2console/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>H2Console</servlet-name>
    <url-pattern>/ddh2console</url-pattern>
</servlet-mapping>
-->

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.

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.

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.