Support #6541
fermé
Des fichiers d'extension .exe et .bat spécifiés comme interdits ne le sont pas
100%
Description
Pour reproduire l'anomalie, il faut :
- interdire l'ajout de fichiers exécutables : soit dans le paramétrage global (file.forbidden.default=.exe, .bat), soit dans le paramétrage d'une application de GED
- créer une publication
- ajouter manuellement un fichier .exe ou .bat (bouton Ajouter un fichier)
Constater que le fichier interdit est ajouté à la publication alors qu'il ne devrait pas.
A noter qu'il n'y a pas d'anomalie lorsque l'on ajoute un fichier .exe ou .bat en passant par le Drag & Drop ou bien via l'import de document (téléchargement d'un fichier manuel ou par Drag & Drop).
A noter également que pour les autres extensions, tout fonctionne.
Mis à jour par Nicolas Eysseric il y a environ 9 ans
- Dupliqué par Support #7064: Interdiction de fichiers dont l'extension est ajouté
Mis à jour par Yohann Chastagnier il y a environ 9 ans
Les fonctionnalités d'interdire ou d'autoriser des fichiers, #3146, a été mise en place dans le but premier d'autoriser ou d'interdire des types de contenu.
Les paramètres applicatifs associés Fichiers autorisés et Fichiers interdits proposent à l'utilisateur de renseigner pour chacun une liste d'extension de fichier.
Lorsqu'un utilisateur attache un nouveau fichier, et lorsque ces paramètres sont renseignés, le traitement associé ne vérifie pas si ce dernier est autorisé ou interdit par rapport à l'extension du fichier, mais plutôt par rapport à leur type, où plus précisément par rapport à leur mime-type.
Techniquement, la liste des extensions de ces deux paramètres applicatifs sont donc traduites en listes de mime-types interdits et/ou autorisés, et le traitement de vérification valide que le mime-type du fichier envoyé fait bien partie de la liste de ceux autorisés et ne fait pas partie de ceux interdits.
Le fichier SILVERPEAS_HOME/org/silverpeas/util/attachment/mime_type.properties contient un mapping 1-1 entre extensions de fichier et mime-type. C'est à partir de ce dernier que sont calculés les mime-types à partir des noms de fichier (pour les contenus de fichier, c'est la librairie tika qui est utilisée).
Le choix de vérifier par rapport au mime-type n'est en quelque sorte pas négociable. En effet, si ce traitement était comparé par rapport aux extensions, en imaginant par exemple que les .doc soient interdits, comment le système pourrait empêcher un utilisateur de pousser un .doc.toto ?
Il est vrai que pour le glisser/déposer (comme expliqué dans le REDMINE #5710), une première vérification est faite sur le fichier avant son envoi, et dans ce cas, comme le fichier n'est pas encore téléchargé sur le serveur, le mime-type va être calculé par rapport au nom du fichier. Comme c'est exactement de cette façon que sont calculés les mime-types à partir des deux paramètres applicatifs (c'est à dire calcul du mime-type à partir d'un nom de fichier, et pas à partir d'un contenu), l'utilisateur va avoir la sensation que son paramétrage est bien pris en compte. Mais par exemple, si les .jpg sont interdits, il suffit à l'utilisateur de le renommer en .jpg.capasse et ce premier contrôle est déjà cassé. C'est pour cela que dans le glisser/déposer il y a ce premier contrôle, plus là pour éviter à l'utilisateur d'attendre la fin de son envoi de fichier pour avoir une erreur, et puis il y a surtout un deuxième contrôle effectué une fois que le fichier est sur le serveur, où le mime-type est calculé cette fois-ci à partir du contenu du fichier. De cette manière, par rapport à notre exemple, le renommage du .jpg.capasse est bien bloqué.
Il y a une limite à ce système pour les fichiers plus d'ordre technique ou simple, par exemple .bat ou .txt (pas des fichiers de contenu, comme .odt ou .doc par exemple), dans le sens où le mime-type qui va être calculé à partir du fichier physique risque d'être le même pour chacun : text/plain.
Aussi, pour les fichiers plus complexes, comme un .exe, il existe plusieurs mime-type potentiels, alors que le fichier mime_types.properties ne permet de spécifier qu'un seul mime-type pour une extension. Une feature a été saisie pour essayer de remédier à cela (passer d'un mapping 1-1 à 1-N): #7087.
- soit mettre en place des règles de filtrage technique sur le système du serveur
- soit spécifier la liste complètes des fichiers de contenu, .doc .odt .jpg etc., qui est autorisée, plutôt que de définir une myriade de fichiers interdits compliquée à résoudre. De plus, renseigner les fichiers autorisés permet un niveau de sécurité naturellement bien plus élevé...
Toutefois, si cela est vraiment nécessaire, le traitement de vérification peut être modifié (évolution) afin de vérifier un fichier par rapport à son mime-type et aussi par rapport à son extension.
Il peut également être envisagé de modifier les libellés et description des paramètres applicatifs, de manière à faire comprendre plus précisément à l'utilisateur comment l'extension qu'il renseigne va être interprétée.
Mais encore une fois, proposer la liste des fichiers autorisés me semble être une meilleure option lorsque l'objectif est de bloquer des fichiers techniques et potentiellement dangereux.
Mis à jour par David Lesimple il y a plus de 3 ans
- Statut changé de Feedback à Closed
- % réalisé changé de 0 à 100