Il existe de nombreuses bonnes raisons générales de suivre le minimalisme en matière d'autorisations, mais dans le contexte d'un hébergeur LAMP, les quelques-unes qui viennent immédiatement à l'esprit sont
- Sur une plate-forme d'hébergement partagé, les autres utilisateurs partageant votre hôte peuvent désormais lire et écrire dans vos scripts.
- Sur un hôte dédié, des processus malveillants peuvent lire/écrire et supprimer accidentellement vos fichiers. Disons qu'il y a un processus de journalisation personnalisé en cours d'exécution en arrière-plan en tant qu'utilisateur personne qui a un bogue qui l'amène à essayer de
rm -rf /. Maintenant, généralement, cela sera inoffensif car il n'y aura pratiquement aucun fichier sur lequel personne ne devrait avoir des autorisations d'écriture, mais ce processus malveillant emportera désormais vos fichiers avec lui. - Pour défigurer votre site Web, quelqu'un n'a besoin d'y accéder qu'en tant qu'utilisateur, par exemple
nobodyou un tel compte fictif. Généralement, l'attaquant devrait effectuer une autre attaque d'escalade au niveau de l'utilisateur pour se rendre à l'endroit où il peut faire des dégâts. C'est une vraie menace. Certains services non critiques peuvent être exécutés sous des comptes factices et peuvent contenir une vulnérabilité.
Cela augmente considérablement le profil de vulnérabilité de votre site Web aux activités malveillantes, car il suffit de s'introduire dans un seul compte.
Quiconque accède à votre système avec n'importe quelle connexion peut faire ce qu'il veut sur vos pages, y compris les modifier pour lire "Ce site Web n'est vraiment pas sécurisé, veuillez donc me donner les informations de votre carte de crédit."
EDIT :(Pour clarifier et répondre aux commentaires)
De nombreux serveurs ont plus d'un but dans la vie. Ils gèrent plusieurs services. Si vous isolez soigneusement ces services les uns des autres en attribuant à chacun un utilisateur unique et en gérant les autorisations de fichiers en conséquence, oui, vous êtes toujours dans l'eau chaude si quelqu'un compromet les informations d'identification d'un compte, mais les dommages qu'ils peuvent causer sont limités à ce service. . Si vous n'avez qu'un seul compte générique et définissez l'ensemble du système de fichiers sur 777, un compte compromis compromet tout sur la machine.
Si votre serveur est dédié uniquement à l'exécution d'Apache/PHP et ne sert à rien d'autre dans la vie, et qu'il n'y a qu'un seul compte sous lequel Apache/PHP est exécuté, avoir ce compte compromis est aussi bon que d'avoir toute la machine compromise à partir du du point de vue de votre application (bien que vous devriez toujours avoir des fichiers système protégés et non accessibles en écriture par le compte utilisé pour exécuter PHP... cela ne devrait toujours être possible que pour un compte administrateur/root).
S'ils peuvent écrire un fichier et qu'il est exécutable, ils peuvent le changer en quelque chose qui s'exécute sur votre machine (exécutable ou script), puis utiliser le shell_exec de PHP pour exécuter cet exécutable. Si vous êtes configuré pour ne pas autoriser shell_exec, ils peuvent également modifier votre configuration
Voici un scénario :
- Vous avez un répertoire non protégé dans lequel les utilisateurs peuvent télécharger.
- Ils téléchargent deux fichiers :un script shell et un fichier php qui a un
system()appelez-le au script shell. - ils accèdent au script php qu'ils viennent de télécharger en visitant l'url dans leur navigateur, provoquant l'exécution du script shell.
Si ce répertoire est 777, cela signifie que n'importe qui (y compris l'utilisateur apache, sous lequel le script php s'exécutera) peut l'exécuter ! Si le bit d'exécution n'est pas défini sur ce répertoire et vraisemblablement les fichiers à l'intérieur du répertoire, alors l'étape 3 ci-dessus ne ferait rien.
modifier à partir des commentaires :ce ne sont pas les autorisations du fichier PHP qui comptent, c'est le system() appel à l'intérieur du fichier PHP qui sera exécuté en tant qu'appel système Linux par l'utilisateur Linux apache (ou tout ce que vous avez défini pour l'exécution d'Apache), et c'est PRÉCISEMENT là où le bit d'exécution compte.