Protéger le code serveur des attaques par fichiers envoyés et saisies utilisateur

## Avant de modifier, suivre les données externes et trouver les chemins de code similaires Considérez que les fichiers téléversés, le contenu des archives, les paramètres de requête, les manifestes, les métadonnées et les identifiants d’appareil peuvent être contrôlés par un attaquant, même lorsque l’utilisateur est authentifié. Avant de modifier un chemin de code sensible : 1. Déterminez où entrent les données non fiables, comment elles sont transformées et toutes les opérations de fichier, de processus, de base de données, d’affichage, de redirection et de réseau qu’elles peuvent atteindre. 2. Recherchez les implémentations apparentées qui effectuent la même opération. Incluez les autres formats, les vues d’API et du Web, les flux binaires et de code source, ainsi que les anciens points d’appel. 3. Réutilisez ou étendez les fonctions de sécurité centralisées au lieu de disperser des contrôles improvisés dans les vues et les gestionnaires. 4. Examinez les schémas de vulnérabilité antérieurs lorsqu’ils sont disponibles, en particulier les correctifs incomplets qui ne protégeaient qu’un seul chemin. 5. Maintenez la cohérence des importations et des conventions locales, puis exécutez l’analyse statique requise et les tests ciblés jusqu’à ce qu’ils se terminent correctement. Un correctif de sécurité est incomplet si un chemin équivalent peut encore atteindre l’opération vulnérable. ## Valider les données de requête et les fichiers envoyés à l’entrée, et exiger connexion et permissions Validez l’entrée brute avant qu’elle ne devienne un chemin, un argument de commande, une valeur de requête, une redirection, une chaîne affichée ou un hôte externe. - Utilisez des formulaires ou des schémas typés comme couche principale de validation. - Utilisez des champs à choix fini pour les paramètres dont l’ensemble des valeurs valides est connu. - Placez la logique de rejet propre à chaque champ dans la couche de validation et renvoyez une réponse d’erreur standard lorsque la validation échoue. - Validez les identifiants selon leur format exact avant de les utiliser dans des chemins ou des recherches. - Vérifiez les octets magiques, les limites de taille et les listes d’extensions autorisées des téléversements ; une extension seule ne suffit pas. - Traitez les valeurs des manifestes et des métadonnées comme des entrées non fiables. Les gestionnaires sensibles doivent appliquer tous les contrôles pertinents : - authentification ; - autorisation fondée sur le rôle ou les droits ; - restriction explicite de la méthode HTTP ; - protection CSRF des changements d’état lancés depuis le navigateur. Ne désactivez pas l’échappement des gabarits et ne marquez pas un contenu non fiable comme sûr. Lorsque vous construisez une sortie en dehors d’un gabarit à échappement automatique, encodez la valeur selon le contexte de destination. ## Garder les chemins de fichiers et l’extraction ZIP/TAR dans le dossier prévu Utilisez deux couches de protection pour les chemins du système de fichiers : 1. Rejetez les formes brutes dangereuses telles que les segments de traversée, les chemins absolus, les contournements encodés et les caractères non valides. 2. Après avoir construit le chemin, résolvez-le sous sa forme canonique et vérifiez qu’il reste dans la racine prévue. Avant de lire un objet du système de fichiers, rejetez les liens symboliques, les canaux nommés, les fichiers de périphérique et les autres types inattendus lorsque l’opération attend un fichier ordinaire. Pour l’extraction TAR : - Privilégiez un filtre d’extraction fourni par l’environnement d’exécution, appliqué à chaque entrée et tenant compte de son type, qui rejette les traversées, les chemins absolus, les fichiers de périphérique et les liens sortant de la destination. - Ne vous fiez pas à une vérification fondée uniquement sur le nom ou sur `abspath` ; elle ne résout pas les liens symboliques. - Si aucun filtre intégré sûr n’est disponible, rejetez les liens symboliques et physiques, résolvez la destination avec `realpath` et validez-la immédiatement avant d’extraire chaque entrée. - Évitez de valider l’ensemble puis de l’extraire en bloc, car l’état du système de fichiers peut changer entre les deux phases. Pour l’extraction ZIP : - Vérifiez chaque nom d’entrée afin de détecter une traversée avant l’extraction. - Résolvez la destination proposée et vérifiez qu’elle se trouve dans la racine d’extraction. - N’extrayez l’entrée qu’après qu’elle a réussi les deux contrôles. Chaque garde qui échoue doit arrêter l’opération dangereuse avec `continue`, `return` ou `raise`. Consigner un avertissement sans bloquer l’exécution ne constitue pas un contrôle de sécurité. ## Neutraliser les saisies selon leur usage, par exemple en SQL ou en commande shell - Transmettez les arguments du sous-processus sous forme de liste. N’insérez jamais une entrée non fiable dans une chaîne de commande de l’interpréteur. - Utilisez des opérations paramétrées de l’ORM ou du générateur de requêtes. Ne construisez jamais de SQL par formatage de chaîne. - Échappez le contenu contrôlé par l’utilisateur avant de l’afficher hors d’un contexte à échappement automatique. - Assainissez les formats actifs tels que SVG avant leur affichage. - Retirez les sauts de ligne et les caractères de contrôle des champs de journal dérivés de l’utilisateur afin d’empêcher l’injection dans les journaux. - Générez des noms de fichier sûrs avant de les placer dans les en-têtes de réponse. - N’autorisez que des destinations de redirection relatives et validées. - Avant une requête sortante, résolvez et validez l’hôte, puis rejetez les adresses de boucle locale, privées, locales au lien, de multidiffusion et les autres plages interdites. Appliquez une validation propre à chaque contexte plutôt qu’un seul assainisseur générique. Une valeur sûre pour un filtre de base de données peut rester dangereuse dans un nom de fichier, une commande d’interpréteur, un fragment HTML, une entrée de journal, une redirection ou une URL. ## Terminer par une checklist de sécurité et justifier chaque point Pour chaque modification concernant les E/S de fichiers ou les entrées utilisateur, vérifiez les éléments pertinents : - [ ] L’entrée brute est validée avant la construction du chemin. - [ ] Les chemins construits sont maintenus sous forme canonique dans la racine prévue. - [ ] Les liens, canaux et types de fichiers inattendus sont rejetés avant la lecture. - [ ] Les entrées d’archive sont validées individuellement avant l’extraction. - [ ] Les arguments de l’interpréteur sont transmis sans interpolation de chaîne. - [ ] Les valeurs affichées sont échappées et le contenu actif est assaini. - [ ] Les hôtes externes et les destinations de redirection sont limités. - [ ] Les valeurs de journal dérivées de l’utilisateur sont assainies. - [ ] L’accès à la base de données utilise des opérations paramétrées. - [ ] Chaque branche de rejet empêche l’opération dangereuse. - [ ] Les chemins de code équivalents reçoivent le même correctif. - [ ] Les tests ciblés couvrent les entrées acceptées, les entrées rejetées et les tentatives de contournement. - [ ] L’analyse statique et les tests pertinents se terminent avec le code de sortie zéro. Présentez les éléments probants de chaque contrôle terminé et indiquez tout chemin qui n’a pas pu être vérifié.