Nouvelle version: S-Filer Portal v4.8.3

Okiok publie la version 4.8.3 de S-Filer Portal™.

Correctifs de sécurité

Cette version comprend plusieurs correctifs de sécurité issus de tests d’intrusion menés sur l’application, veuillez faire la mise à jour dès que possible:

• Retrait d’un servlet de test qui était à l’écoute des connexions RMI sur le port 5001. En raison de failles dans le protocole RMI, ce servlet introduisait une vulnérabilité d’exécution de code à distance. Ce port n’était pas utilisé par S-Filer, il n’était donc pas ouvert dans les pare-feux de la plupart des installations. En l’absence de pare-feu, par contre, ce port était accessible et vulnérable.
• Ajout de jetons « Cross Site Request Forgery » (CSRF) dans toutes les parties de l’application afin de prévenir les attaques CSRF.
• Correction d’une vulnérabilité de script intersites (XSS) dans la fonctionnalité de rapport de l’état des transferts. Ce XSS était exclusivement lié à la session de l’utilisateur et donc difficile à exploiter en pratique. Combiné à la vulnérabilité CSRF, cependant, il permettait à un attaquant de forger une requête pour le déclencher.
• La console de configuration permettait de saisir une adresse IP afin de se connecter aux différents serveurs de S-Filer Portal. Si un administrateur ou un utilisateur malveillant saisissait l’adresse IP d’un site externe et qu’aucun pare-feu n’empêchait la connexion externe, le serveur tentait une connexion vers ce site. Pour atténuer ce risque, la console ne peut désormais se connecter qu’au serveur sur lequel elle est installée, et le champ d’adresse IP a été retiré de la page de connexion.
• S-Filer Portal comprend une fonctionnalité de liens profonds, notamment pour les notifications courriel, où l’URL contient l’UUID du fichier mentionné dans la notification. Lorsque l’utilisateur n’est pas authentifié, S-Filer intercepte cette requête et redirige vers la page d’authentification en mémorisant l’URL d’origine. Ce mécanisme de redirection pouvait être détourné en forgeant une URL particulière qui affichait la page de connexion de S-Filer puis redirigeait vers un site malveillant. Le mécanisme est corrigé et n’autorise plus que les redirections vers des URL relatives à S-Filer Portal.
• Une option a été ajoutée pour que le témoin de session porte l’indicateur « secure », qui indique qu’il ne sera transmis que sur des connexions sécurisées (HTTPS). Cette option est activée par défaut, mais certains environnements de test ou de développement fonctionnent en HTTP et doivent donc la désactiver, sans quoi ils ne fonctionneront pas.
• Une option a été ajoutée pour insérer dans les réponses les en-têtes HTTP contre le « clickjacking », afin de protéger contre ce type d’attaque. Cela empêche effectivement S-Filer d’être intégré dans un cadre (Frame ou iFrame). Les clients qui intègrent la solution dans un cadre devront désactiver cette option, activée par défaut.
• Une option a été ajoutée pour insérer dans les réponses les en-têtes HTTP Strict Transport Security (HSTS). Ceux-ci indiquent aux navigateurs que le site (toute page du même domaine) ne doit être consulté qu’en HTTPS. Cela prévient les attaques de type « SSL strip », où un utilisateur malveillant intercepte la première requête HTTP puis réécrit toutes les URL pour rester en HTTP plutôt qu’en HTTPS. Avec cette protection, les navigateurs émettent la première requête directement en HTTPS. Une seconde configuration indique la durée pendant laquelle les navigateurs doivent mémoriser ce réglage. Dans S-Filer, elle est de 1 jour par défaut, car au moment du déploiement initial, s’il s’avère que des sites du même domaine doivent être accessibles en HTTP, la configuration peut être renversée et après 1 jour les navigateurs des clients y accéderont de nouveau (ces sites seront inaccessibles pendant 1 jour). Une fois cette configuration déployée sans problème pendant un certain temps, la valeur peut être portée à un an ou plus, afin de mieux protéger les utilisateurs.
• Partout où l’application est à l’écoute d’un port, elle écoutait auparavant sur l’adresse IP « 0.0.0.0 », ce qui signifie qu’elle écoutait sur toutes les interfaces réseau (toutes les adresses IP). Un champ supplémentaire est maintenant ajouté à chacun de ces endroits, permettant de préciser l’adresse IP sur laquelle le serveur doit écouter. Le serveur ne devrait parfois écouter que localement: si un proxy inverse est installé sur le même serveur, par exemple, le port web de S-Filer peut écouter sur 127.0.0.1 afin que les connexions directes au port web ne soient possibles que depuis l’hôte local.
• Mise à jour des versions de plusieurs bibliothèques pour lesquelles des CVE avaient été publiées.

Fonctionnalités et corrections de bugs

Cette version comprend également des fonctionnalités mineures et des corrections de bugs:

• Les utilisateurs adoptés de comptes Active Directory pour lesquels une date d’expiration était définie voyaient leur date d’expiration S-Filer fixée au moment de l’adoption initiale. Cette date n’était toutefois pas mise à jour lorsque le compte était modifié lors des adoptions suivantes. Ce problème est corrigé et la date d’expiration est maintenant mise à jour correctement.
• Une option a été ajoutée pour permettre aux administrateurs de système de dépasser les valeurs globales de durée de vie (« Time to live », TTL) des fichiers au moment de préciser le TTL d’une communauté. Cela permet des scénarios où le TTL global est court alors que certaines communautés servant au stockage ont un TTL plus long. AVERTISSEMENT: le TTL d’un fichier téléversé dans une communauté est celui qui était en vigueur au moment du téléversement, modifier le TTL de la communauté par la suite n’a aucun effet sur les fichiers déjà téléversés.
• La valeur globale de TTL du système est maintenant affichée au moment de définir le TTL d’une communauté, afin de savoir facilement si celui-ci est valide.

Problèmes connus

Ces problèmes mineurs seront corrigés dans les prochaines versions:

• La mise à jour de la machine virtuelle Java vers Java 8 a forcé la personnalisation des paramètres Kerberos à se faire dans un fichier krb5.ini du répertoire conf du serveur. Malheureusement, le fichier krb5.ini n’est pas ajouté lors de la mise à jour d’une installation existante, et les paramètres de royaume définis dans le configurateur doivent être ajoutés manuellement à ce fichier. Veuillez contacter Okiok pour obtenir de l’aide dans la création du bon fichier krb5.ini pour votre installation.
• La machine virtuelle mise à jour ne migre pas non plus le fichier cacerts: si des certificats avaient été ajoutés au magasin de confiance de la machine virtuelle (cacerts), ils doivent être ajoutés dans la nouvelle. De plus, les fichiers « Unlimited Strength Jurisdiction Policy Files », requis dans la machine virtuelle pour utiliser la cryptographie forte, ne sont pas présents dans le JRE installé. Ils doivent être téléchargés depuis le site de téléchargement d’Oracle.
• La nouvelle mesure de sécurité des jetons CSRF a entraîné de nombreuses modifications au code javascript de l’application. Malheureusement, les fichiers javascript sont fortement mis en cache par les navigateurs et les anciens fichiers provoquent souvent des erreurs de validation du jeton CSRF. Forcer le rafraîchissement des fichiers en cache (avec CTRL-F5) devrait résoudre l’erreur, mais l’opération doit être effectuée par les clients qui accèdent au site.

Mise à jour

Cette section décrit une mise à jour de 4.8.2

• Cette mise à jour n’implique pas de changement au schéma de base de données.
• Cette mise à jour ne modifie pas les thèmes de l’interface utilisateur.
• Cette mise à jour ne modifie pas les modèles de courriels.