Est-il prudent de donner une autorisation en écriture au compte utilisateur _www?
Je souhaite utiliser PHP pour modifier certains de mes fichiers, mais quelqu'un d'autre peut-il utiliser ce compte pour modifier mes fichiers sans mon accusé de réception?
Il est généralement déconseillé de permettre à www ou à Apache d’avoir un accès en écriture. Toutefois, cela peut être fait en toute sécurité en limitant l’accès à un seul répertoire et en n’autorisant aucun exécutable dans ce répertoire.
Par exemple, la racine de doc de votre site basé sur php est /var/www/exemple.com. Vous voudriez que votre serveur Web soit configuré de manière à ce que le seul point d'accès exécutable php soit /var/www/exemple.com/index.php et que le seul répertoire Le serveur Web peut écrire dans /var/www/example.com/files. C’est souvent ainsi que les applications Web php gèrent la manipulation d’images.
Vous voudriez également que votre serveur Web soit configuré de manière à ce qu'aucun fichier php ne puisse être exécuté à l'intérieur du répertoire/files.
En outre, vous pouvez transmettre ces fichiers via une autre source. php exécute un script shell qui écrit les fichiers, mais cela peut être très compliqué à faire en toute sécurité et cela peut ajouter un autre vecteur d'attaque. Rappelez-vous toujours que plus un processus est compliqué, plus il peut y avoir de problèmes.
Parlez-vous d'autoriser le téléchargement de contenu via le serveur Web ou autre chose?
Quoi qu'il en soit, vous devez vous assurer que les autorisations sont déjà configurées pour que votre code PHP puisse uniquement écrire dans des emplacements (répertoires) désignés. séparer du contenu de votre site Web. Cela peut être difficile sur un hébergement mutualisé pas cher.
Chargement de contenu
La réponse de Frank est généralement correcte, mais manque de détails et est un peu trompeuse.
Vous DEVEZ vous assurer que tout ce qui est chargé sur le serveur ne sera pas exécuté par le serveur. Et vous devriez prévoir plusieurs mesures pour empêcher cela.
Vous devez traiter toute information fournie sur le contenu avec suspicion. Les chemins de fichiers peuvent être exploités ( chemin traversant ). Les types MIME fournis par l'utilisateur n'ont essentiellement aucun sens. Ne soyez pas dupe de l'habitude de Microsoft de traiter une extension de fichier et un type MIME comme représentant le même fait.
Même les noms de fichiers ne doivent pas être approuvés - une fois que vous avez validé le contenu, stockez le fichier en utilisant le chemin d'accès, le nom de fichier et l'extension que vous avez générés.
La solution la plus simple pour empêcher l'exécution est de s'assurer que le contenu téléchargé est stocké en dehors de la racine du document et que tous les accès sont modérés par votre site. Cela garantit que le fichier ne peut pas être appelé à distance en tapant simplement l'URL dans un navigateur. Il ne protège pas contre inclusion de fichier local vulnérabilités.
Mais si vous avez un forfait d'hébergement bon marché, cela ne sera peut-être pas une option. Vous pouvez également stocker le fichier dans la racine du document, mais dans un format transformé (crypté, par exemple) avec accès médiatisé (protection contre l'invocation à distance et le LFI). Vous pouvez désactiver le traitement de PHP (c'est-à-dire l'appel à distance) sur la configuration principale d'Apache ou .htaccess à l'aide de moteur php_flag désactivé . Là encore, cela n’empêche pas le LFI.
Pour une validation triviale du contenu, utilisez finfo_file() et vérifiez que le type MIME correspond à une liste blanche. Cela ne fait que vérifier les premiers octets d’un fichier et peut être contourné. Pour une meilleure protection, modifiez le type de fichier (jpeg, par exemple, en webp, gif en png, MSWord en HTML, etc.) à l'aide d'un outil performant.
Autre chose
Cela dépend vraiment des spécificités de ce que vous essayez de changer.
Vous ne devez PAS créer de code exécutable - en particulier PHP ou des fichiers binaires natifs. Javacript et CSS sont légèrement moins risqués (utilisez un système de templates). Les images, les PDF et les fichiers audio/vidéo doivent être relativement sûrs - mais méfiez-vous des autorisations que vous accordez à votre environnement d'exécution PHP lorsque vous exécutez des fichiers binaires locaux pour effectuer des opérations.