34. Uploads, ZIP et budgets par couche

Comprendre le mécanisme

Un upload traverse plusieurs plafonds : proxy, moteur PHP, formulaire et logique de traitement. Le type MIME déclaré et le nom client sont des assertions non fiables. Une archive ajoute un risque de chemins dangereux, de fichiers inattendus et d’expansion excessive. La taille compressée, la somme décompressée, le nombre d’entrées et la taille de chaque image sont des dimensions distinctes à borner.

Raisonner et vérifier

Un découpage binaire d’un ZIP ne produit pas nécessairement plusieurs archives indépendantes lisibles par un importeur. Pour fractionner des réalisations, chaque partie doit contenir son manifeste JSON et les images qu’il référence. Si une seule image dépasse le plafond réseau, répartir les lignes ne suffit pas : il faut adapter une copie de l’image ou choisir un transfert séparé compatible avec le contrat d’import.

Budget multipart

Le multipart peut dépasser la taille du ZIP seul. L’enveloppe et les autres champs ajoutent des octets. Prévoyez fichier, métadonnées et champs de formulaire dans la limite de requête. Un ZIP sous un plafond exprimé pour le corps complet peut encore être refusé lorsque l’enveloppe le fait dépasser.

Découpe binaire

Un fractionnement binaire ne crée pas des ZIP indépendants. L’importeur a besoin d’une structure d’archive complète. split produit des fragments d’un flux, pas plusieurs archives ZIP indépendantes. Un importeur qui attend chaque fois une archive complète ne peut pas utiliser directement ces fragments sans mécanisme de réassemblage.

Parties autonomes

Des parties importables doivent inclure leurs données référencées. Le contrat de l’import exige les références nécessaires. Pour reconstruire plusieurs imports, chaque archive doit contenir un manifeste valide et toutes les images référencées par ses éléments. Si une seule image dépasse le plafond, diviser uniquement les lignes ne résout pas ce cas.

Expansion

La taille décompressée doit être bornée. Le volume extrait peut être bien supérieur. Limitez taille totale extraite et taille par fichier pendant la lecture. Un petit fichier compressé peut demander beaucoup de stockage et de mémoire ; son poids réseau ne borne pas ces ressources.

Chemins

Les chemins des entrées doivent rester dans le périmètre d’extraction. Des chemins hostiles peuvent sortir du répertoire prévu. Refusez les chemins absolus et les sorties du répertoire prévu après résolution contrôlée. Examinez aussi liens et formes spécifiques à la plateforme pour éviter qu’une entrée écrive hors du périmètre d’extraction.

Nombre de fichiers

Le nombre d’entrées doit être limité. De nombreuses entrées peuvent consommer des ressources. Bornez entrées, profondeur et opérations, même lorsque chaque fichier est petit. Une archive peut épuiser temps, inodes ou descripteurs sans dépasser une simple limite de taille totale.

Doublons

L’import doit définir le traitement des doublons. La reprise exige une politique explicite. Définissez si un identifiant existant est refusé, fusionné ou mis à jour. Cette politique doit rester stable entre parties et reprises ; sinon un fractionnement peut créer des doublons ou écraser des réalisations.

Original conservé

Un original doit être conservé avant transformation. Une copie permet de vérifier et reprendre sans perte. Travaillez sur une copie et conservez l’archive source avant transformation. Vérifiez manifestes et références après reconstruction afin de pouvoir revenir à l’original si un regroupement omet une image.

Type réel

Le type déclaré par le client doit être vérifié. La déclaration n’est pas une analyse du contenu. Le nom .zip et le MIME client sont des affirmations. Le parseur et les règles de contenu doivent vérifier format et structure admise avant extraction ou publication des fichiers.

Import privilégié

L’autorisation et le CSRF restent nécessaires sur l’import admin. Le format ne prouve pas les droits de l’acteur. Un formulaire d’administration reste soumis à authentification, droit d’import et protection CSRF adaptée. Une limite de taille ou un ZIP valide n’établit pas l’autorisation de modifier le portfolio.

Atelier guidé : lire, expliquer et vérifier le code

# Illustration de découpe binaire uniquement :
split -b 500000 portfolio.zip lab-part-
# L’importeur attend pour chaque envoi une archive ZIP complète.

La commande split découpe seulement le flux binaire de portfolio.zip. L’importeur exige pourtant un ZIP complet à chaque envoi. Reconstituez des archives autonomes à partir des données et dépendances, puis vérifiez leur validité et leur taille multipart estimée avant de les proposer à l’import.

Les octets sont coupés sans reconstruction logique. Le suffixe ne répare pas la structure. Le seuil ne recrée pas les références ou contenus. Il faut reconstruire des archives conformes avec leurs données nécessaires.

Travail pratique : Fractionnez un petit jeu fictif en archives autonomes, puis testez taille réseau, intégrité, chemins et doublons à la réimportation.

Critères de correction : Vérifiez chaque archive avec le lecteur réel, importez toutes les parties dans une base de test isolée et comparez champs et images. Rejouez l’import pour contrôler l’idempotence. Gardez les sources intactes pour comparer les résultats.

PDF : admission, stockage et restitution sont trois décisions

Un nom .pdf et un MIME client application/pdf restent des déclarations. Vérifiez le format admis et sa structure avec des composants adaptés, en bornant taille, temps et ressources du traitement. Aucun scanner unique ne garantit l’absence de tout danger dans un document.

Générez un nom interne indépendant du nom original et stockez hors d’un périmètre exécutable ou publiquement listable. Conservez une relation métier vers le propriétaire. Lors de la restitution, autorisez l’action avant lecture puis servez un type explicite, une disposition adaptée et une politique de cache cohérente avec la confidentialité.

Testez fichier malformé, dépassement, nom de chemin hostile et demande par un autre compte. Vérifiez aussi les routes alternatives de fichiers et les copies temporaires. Un upload correctement refusé ne doit laisser aucun document consultable, tandis qu’un import accepté ne doit pas contourner l’autorisation simplement parce que son URL est opaque.

Points de vigilance : Les métadonnées client ne sont pas fiables et le stockage exécutable augmente le risque. Une extension ne prouve pas le type ni l’innocuité du contenu. La limite de taille ne contrôle ni la nature du fichier ni son exécution ou son accès. Ces contrôles se complètent ; une analyse de contenu adaptée reste utile et aucun scanner ne garantit l’absence de danger.