Les dangers du mode ASCII Facile

Les dangers du mode ASCII


Article de phpBB : The dangers of ASCII mode

Les dangers du mode ASCII

Le protocole FTP est le moyen le plus utilisé pour transférer des fichiers vers et à partir d’un serveur. Quand la spécification FTP a été écrite, certaines fonctionnalités pratiques ont été recommandées aux éditeurs de logiciels Clients FTP. Cela prit forme via la définition de quatre types de données. Avec ces définitions, les clients FTP peuvent prendre en charge les transformations de données pour vous éviter de le faire à chaque fois que vous transférez un fichier.

Les types de données sont : ASCII, EBCDIC, Image et Local. Les deux premiers sont des types de jeux de caractères vers lesquels le fichier local peut être converti pendant l'envoie au serveur. Le type Image est désormais communément appelé « mode binaire » et permet de transférer les données sans aucune altération. Le type Local permet aux hôtes de spécifier la taille d’octets pour le stockage et la transmission des données. Dans cet article, je mettrai l’accent sur les types ASCII et Image et ce qui peut être problématique si vous choisissez le mauvais mode de transfert.

Pourquoi utiliser le mode ASCII ?
En plus de convertir le jeu de caractères local en NVT-ASCII, les fins de ligne sont converties au style utilisé sur la machine cible. Si un fichier est transféré d’une machine Windows vers une machine Linux, les fins de ligne seront converties du CRLF en LF et inversement lorsque vous téléchargerez le fichier. Ce fut certainement pratique il y a quelques années, sinon les lignes des fichiers se seraient terminées par des sauts de lignes intempestifs dus à l'ajout de CRs (*nix) ou tout se serait retrouvé sur la même ligne dû au manque de CRs (Windows). Toutefois, aujourd’hui, ce n’est plus un problème. Les éditeurs de texte, des deux systèmes d’exploitation, peuvent désormais convertir les fins de ligne dans le type souhaité. Sous Linux/GNU, il y a habituellement une indication pour cela lorsque vous ouvrez le fichier.

    vi:
    « test.txt » [dos]

    nano:
    « [ Lire 4 lignes (Converties du format DOS) ] »

Sous Windows, WordPad lit les deux formats sans problèmes. Cependant, le Bloc-notes ne peut lire que le CRLF, alors si vous voyez tout le fichier avec une seule ligne, vous saurez pourquoi.

Comment le client doit choisir son mode de transfert de fichiers ?
La seule façon de travailler sur de multiples modes est de savoir s’il y a moyen pour le client FTP de savoir comment il doit transférer les fichiers que vous avez placés en file d’attente. Cela se fait grâce aux extensions de fichier. Les clients contiennent généralement une liste d’extensions configurable qui doivent être transférées en mode ASCII. De plus, certains clients vous permettent de forcer un mode spécifique pour tous les transferts. Mettez « Mode Automatique ». Dans ce mode, le client examinera la liste des extensions et décidera comment transférer le fichier, plutôt que d’utiliser toujours un seul et même mode. Quand un fichier n’a pas d’extension, le client FTP n’a aucune information exploitable lui permettant de décider comment traiter le fichier. Dans ce cas, les clients devraient toujours transférer le fichier en mode binaire. Cela permettrait d’éviter toute perte de données, si le fichier n'est pas du texte pur.

Quel est le problème ?
Si un fichier est transféré avec le mauvais mode, il risque d’être endommagé. Pour les fichiers de type « texte », le mode choisi pour les transférer n’a pas d’importance, à moins que vous ne vouliez voir à quoi ressemble réellement le fichier sur le serveur. Pour tout type de fichiers binaires (images, exécutables, etc.), le transfert en mode ASCII va totalement les détériorer. Votre fichier contient un 0x0A (LF) ? Eh bien maintenant, il a 0x0D 0x0A (CRLF) à cet endroit. C’était une image ? C'est malheureux, parce que maintenant le rendu sera totalement différent (voire inexploitable).

corrupt_install.jpg


C’est assez facile à corriger. Il suffit de changer le mode de transfert en Binaire et re-transférez les fichiers sur le serveur.

Le gros problème.
Les sauvegardes. Ces petites choses bien pratiques, vous permettant de bien dormir la nuit, vont répliquer vos données dans le cas où une erreur surviendrait. Elles vous permettent également de changer d’hébergeur si le besoin s'en fait sentir. Si votre sauvegarde est corrompue par votre client FTP, vous n’aurez plus que vos yeux pour pleurer après avoir essayé de restaurer vos données. Je l’ai vu plusieurs fois dans nos forums de support : un utilisateur télécharge ses données à partir de son ancien hôte et perd par la suite l’ensemble de ses pièces jointes à cause de la corruption des données et comme l’ancien hébergeur a mis fin à leur contrat il n’a plus aucune sauvegarde exploitable.

Pourquoi les fichiers joints sont-ils corrompus ? Pour votre propre sécurité, les fichiers joints transférés voient leurs noms remplacés par une clé de hachage et leurs extensions de fichiers sont supprimées (Vous pouvez lire ici quelques-unes des raisons de notre gestion des fichiers joints). La plupart des clients FTP respectent la liste des extensions ASCII et chargent tout le reste en mode binaire. Cependant, certains clients FTP comme FileZilla transfèrent par défaut les fichiers sans extension en mode ASCII.

La solution
Trouver la page des paramètres de transfert et s’assurer que les fichiers sans extension ne soient pas définis pour être transférés en mode ASCII. Dans FileZilla, aller dans Édition => Paramètres => Transfert => Types de fichier => Traiter les fichiers sans extension en mode ASCII (décochez cette case !). Alternativement, vous pouvez faire en sorte que votre client transfère toujours les fichiers en mode binaire. Si vous avez un éditeur de texte qui supporte les deux types de fins de ligne, c’est alors sans importance.

Récupérer les fichiers corrompus
A ce stade, la récupération des fichiers n’est pas possible. La seule option est de changer le mode de transfert et de télécharger à nouveau les fichiers, si vous avez toujours accès aux originaux. « Mais je ne peux pas simplement re-transférer les fichiers et laisser les fins de ligne se reconvertir ? ». Malheureusement non ! Les sauts de ligne (LF) existants auraient eu un retour chariot (CR) ajouté devant et les CRLF existants auraient été laissés tels quels. Le transfert aurait converti à la fois les nouveaux et les précédents CRLF en LF. Au final, le fichier est perdu.

Pourquoi ont-ils fait cela ?
Comment un client FTP peut-il supposer qu’un fichier totalement inconnu va être de l’ASCII pur ? Cela me dépasse. C’est une hypothèse qui n’aurait jamais dû être faite. Par défaut, c’est le mode binaire qui doit être utilisé pour les données inconnues. Si vous sauvegardez l’ensemble des fichiers systèmes de Linux/GNU sur votre machine Windows, pour les restaurer plus tard, tous vos binaires seront corrompus puisqu’ils n’auront pas d'extensions de fichier. FileZilla est conscient du problème *, mais ses développeurs répondent avec ce type de commentaire :
- « Tous les fichiers sans extension que je transfère sont en réalité des fichiers texte. ».
C’était il y a trois ans et cela n’a toujours pas changé ! Il y a une semaine, l’un de nos développeurs leur a soumis ce sujet dans leur canal IRC et il n’a eu aucune réponse concrète. La principale réponse qu’il ait reçue est que comme le Bloc-notes de Windows ne peut pas gérer les fins de ligne de style Unix, le mode ASCII devrait rester. Il nous a été également réaffirmé qu’ils n’ont jamais transféré un fichier sans extension qui n’était pas du texte pur. L'omnipotence de FileZilla rend étrange leur vision concernant le type de fichier que vous transférez. Le contrôle d’intégrité du fichier suppose que tous les fichiers inconnus sont des fichiers ASCII et que de les ouvrir dans le Bloc-notes de Windows est tout simplement irresponsable. Laissez les utilisateurs prendre cette décision et laissez la case décochée par défaut !

Il y a eu quelques commentaires de nos propres utilisateurs, qui nous demandent de résoudre ce problème en laissant les extensions existantes ou en ajoutant une extension binaire connue. La première option conduit à des problèmes de sécurité, comme mentionné dans l’article précédemment cité. La seconde déplace les problèmes du client FTP vers nous. Ainsi, nous serions en mesure de supposer ce que pourraient être vos données et comment votre client pourrait les traiter. Cette position n’est pas meilleure que celle prise par FileZilla. L’extension « .phpbb » serait recommandée, mais il est possible qu'un client FTP n'accepte pas les extensions inconnues. Il serait donc préférable de laisser les données telles quelles, des deux côtés.

D’autres clients peuvent faire cela ?
C’est possible, mais je n’ai pas personnellement vu d’autres clients le faire. WinSCP a une mise en page semblable, quand il s’agit de choisir le mode de transfert, mais les fichiers sans extension sont automatiquement transférés en mode binaire. Le module de Mozilla, FireFTP a par défaut le mode binaire pour tous les transferts. Choisir le mode automatique des listes d’extensions va transférer les fichiers en mode ASCII et d’autres en Binaire. Core FTP va par défaut transférer un ensemble spécifique d’extensions en mode ASCII, mais il offre la possibilité de toutes les ignorer et de les transférer en mode Binaire.

Avec les outils dont nous disposons aujourd’hui, je pense que le mode ASCII devrait disparaître. C’est un protocole de transfert de fichiers donc il devrait simplement transférer les fichiers et ne pas chercher à agir intelligemment sur ce que vous pourriez en faire plus tard. En réalité le mode ASCII n’est pas prêt de disparaître, alors configurez vos clients FTP, participez aux rapports de bugs de FileZilla concernant cette problématique.

Note phpbb-fr.com : Depuis le 10 novembre 2013 le ticket #4235 concernant FileZilla est considéré, par les développeurs de FileZilla, comme fermé.
darky
Roi des posts
Roi des posts
 
Rédigé le: 04 Déc 2011 à 17:31
Articles: 1
Contributeurs:
Noter cet article: 123456 Votants: 2
Mots-clés: Les, dangers, du, mode, ASCII

Retourner vers Divers


cron