CWE-434 : téléversement d’un fichier de type dangereux

Douzième du CWE Top 25 2025. Le libellé officiel est Unrestricted Upload of File with Dangerous Type, « téléversement sans restriction d’un fichier de type dangereux ». Le catalogue retient l’abréviation usuelle unrestricted file upload, qui a le défaut d’oublier le mot le plus important de la définition : nous y venons.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Le produit autorise le téléversement ou le transfert de fichiers de types dangereux qui sont automatiquement traités dans son environnement.

Cette dernière proposition est la classe entière. Recevoir un fichier n’est pas une faiblesse : toute application de gestion de documents le fait. Le défaut naît de la conjonction de deux choses : un fichier dont le contenu est choisi par l’extérieur, et un environnement qui le traite tout seul (un serveur web qui interprète les fichiers d’un certain suffixe, un antivirus qui ouvre les archives, une bibliothèque de vignettes qui décode les images, un moteur de rapports qui charge les modèles).

D’où une conséquence pratique à l’opposé de l’intuition. La question utile n’est pas « quels types dois-je interdire ? » mais « que fait mon environnement, sans que je le lui demande, du fichier que je viens d’écrire sur le disque ? ». Une liste d’extensions interdites protège d’une liste de cas connus ; connaître les traitements automatiques protège de la classe.

Le défaut couvre aussi les cas où le fichier n’est pas exécuté mais servi : un document téléversé par un utilisateur et rendu à un autre sous une origine de confiance devient un vecteur de cross-site scripting, un fichier de configuration téléversé dans un répertoire lu au démarrage devient de l’injection de code à retardement.

Sa place dans l’arbre

CWE-434 est une base, fille de la classe CWE-669, « transfert incorrect de ressource entre sphères ». Le vocabulaire du MITRE est ici inhabituellement juste : une sphère est un domaine de confiance, et la faiblesse consiste à faire franchir à une ressource la frontière entre deux sphères sans requalification. C’est la même idée que pour les injections, appliquée non à une chaîne de caractères mais à un fichier entier.

Elle n’a pas d’entrée fille, mais trois pairs qui nomment chacun une façon précise de se tromper, et qui valent le détour car ils décrivent exactement les contournements rencontrés en pratique :

CWE-351, distinction de type insuffisante : l’application croit identifier un type alors qu’elle n’en a vérifié qu’un indice (le suffixe du nom, ou l’en-tête déclaré par le client) ;
CWE-430, déploiement du mauvais gestionnaire : le fichier est confié au composant qui ne devait pas le traiter, par exemple un interpréteur au lieu d’un serveur de fichiers statiques ;
CWE-436, conflit d’interprétation : deux composants de la chaîne ne lisent pas le même type dans le même fichier. C’est le cœur du problème de la détection automatique de type par le navigateur, que le site traite sous le nom de MIME sniffing.

Pourquoi elle est si haut

Parce que les systèmes de publication et leurs greffons dominent le web. Un site de gestion de contenu accepte par construction des images, des documents, des archives de thèmes et de greffons, et son répertoire de téléversement est servi par le même serveur que le reste. Les milliers d’extensions tierces publiées chaque année constituent une source inépuisable de vulnérabilités de cette classe, avec les problèmes de confiance que cela implique.

Parce que les contrôles se font presque toujours au mauvais endroit. Vérifier le suffixe du nom, ou le type déclaré par le navigateur, revient à demander son identité à l’intéressé. Les deux se contrôlent entièrement depuis le client, et c’est pourquoi la même faiblesse réapparaît après chaque correctif qui n’a pas changé de méthode.

Parce que la conséquence est l’exécution. Quand le fichier déposé atterrit dans un répertoire interprété, l’attaquant obtient l’exécution de code sur le serveur ; le score du classement, qui pondère par la gravité, place donc cette classe très haut malgré une fréquence inférieure à celle des injections.

Le mécanisme, et où le site le traite

Le site traite le cas canonique : l’upload de shell PHP déguisé en image dans un CMS montre la chaîne complète, du contrôle contourné au fichier interprété, et il n’y a pas lieu de la reprendre ici. L’attaque MIME sniffing par fichier téléversé complète par le conflit d’interprétation côté navigateur, c’est-à-dire le cas où le fichier n’est pas exécuté sur le serveur mais dans la page de la victime.

Deux renvois pour les voisinages immédiats : la traversée de chemin règle la question de l’emplacement (car un nom de fichier contrôlé décide aussi du répertoire de destination), et l’injection de code décrit ce qui se passe quand le fichier déposé est un modèle ou une configuration chargée plus tard.

Ce qu’une équipe en fait

Stocker hors de l’arborescence servie. C’est le contrôle qui supprime la majorité des conséquences : un fichier qu’aucun interpréteur ne peut atteindre n’est qu’une suite d’octets. Le service de restitution lit le fichier et le renvoie, avec le type et les en-têtes qu’il décide lui-même.

Renommer systématiquement. Un identifiant généré, sans suffixe hérité du client, supprime d’un coup le contrôle du type apparent, le contrôle du chemin et la collision de noms. Le nom d’origine se conserve en base de données, pour l’affichage, et n’intervient jamais dans un chemin.

Vérifier le type par le contenu, et le refuser par liste blanche. La vérification du contenu réel (et, pour les images, la réencodage, qui détruit tout contenu étranger), puis une liste des types admis, dans cet ordre. Une liste de types interdits est toujours incomplète.

Servir avec les bons en-têtes : un type de contenu explicite, l’interdiction de la détection automatique, et une disposition en pièce jointe pour tout ce qui n’a pas à s’afficher dans la page.

Sources

CWE-434: Unrestricted Upload of File with Dangerous Type, MITRE, liste 4.20 : définition, parent CWE-669, pairs CWE-351, CWE-430 et CWE-436.
2025 CWE Top 25, MITRE : rang 12.

🐝 Ce qui arrive si on s’en passe

Une équipe qui aborde la question par la liste des extensions interdites livre un contrôle qui tombe au premier suffixe oublié, à la première casse inattendue, au premier double suffixe. Le défaut est d’autant plus durable que la fonctionnalité marche parfaitement : les utilisateurs téléversent leurs documents, personne ne se plaint, et le répertoire de téléversement grossit sans que quiconque sache ce qu’il contient. Quand le fichier déposé finit par être interprété, l’attaquant obtient un accès permanent au serveur, qui survit au correctif : retirer la faille ne retire pas le fichier déjà déposé. C’est la particularité coûteuse de cette classe : la réponse à incident doit inventorier des mois de téléversements pour savoir si l’un d’eux est encore là, exercice qui demande de distinguer un document légitime d’un fichier maquillé, dans un répertoire dont personne n’a jamais tenu le registre.

🦫 Explication de la marmotte 🍫

Beaucoup de sites permettent d’envoyer des fichiers : une photo de profil, un justificatif, une pièce jointe. Recevoir un fichier n’est pas dangereux en soi. Ce qui l’est, c’est ce que le site fait du fichier ensuite, parfois sans que personne l’ait décidé.

Un serveur web est en effet réglé pour traiter certains fichiers comme des programmes : s’il trouve un fichier d’un certain type dans ses répertoires, il ne le montre pas, il l’exécute. Si quelqu’un parvient à y déposer un fichier de ce type, il ne dépose pas un document : il installe un programme, qu’il pourra ensuite déclencher en visitant une adresse.

C’est le défaut que le catalogue CWE appelle CWE-434. La manière habituelle (et insuffisante) de s’en protéger consiste à regarder la fin du nom du fichier : « .jpg », on accepte ; « .php », on refuse. Mais le nom est choisi par celui qui envoie le fichier, et il existe de nombreuses façons de le déguiser. De même, le navigateur annonce un type au moment de l’envoi, et cette annonce n’est qu’une déclaration de l’expéditeur.

La protection solide ne consiste pas à mieux interroger l’expéditeur, mais à changer les règles du jeu : ranger les fichiers reçus dans un endroit que le serveur ne traite jamais comme un programme, leur donner un nouveau nom choisi par le site, vérifier leur contenu réel plutôt que leur étiquette, et ne les restituer qu’à travers un programme qui décide lui-même comment les présenter. Le fichier reste alors ce qu’il doit être : un document, et non une instruction.

Pages voisines

La citent

CWE-200 : exposition d'information sensible, un impact pris pour une cause

CWE-434 : téléversement d'un fichier de type dangereux

Elle cite

: les deux pages se citent l’une l’autre.