Privilèges sécurisés chmod?

Question

Les privilèges standard de chmod sont "644" pour les fichiers et "755" pour les répertoires, n'est-ce pas?

Dans la plupart des cas, PHP n'a pas besoin d'écrire dans des fichiers ou des répertoires. Donc, je ne pourrais pas prendre les privilèges d'écriture de tous les groupes?

Je pourrais affecter "444" à tous les fichiers et "555" à tous les répertoires.

Cela ne serait-il pas plus sûr?

Merci d'avance!

Remarque: chmod() est sur la liste disable_functions de mon PHP.

Answer 1

Les autorisations par défaut pour les fichiers et répertoires nouvellement créés sont définies par la variable d'environnement umask. Le propriétaire et la racine du fichier peuvent modifier les autorisations.

Si vous n'avez pas besoin d'utiliser chmod dans votre application, laissez-le dans votre liste de désactivation. La façon dont vous devriez considérer la sécurité est: Beaucoup de gens plus intelligents que moi ont maintenant fait de chmod l'une des parties les plus sûres de mon application. Par conséquent, je vais passer mon temps disponible à sécuriser les autres parties. Rendre votre application en lecture seule, sur le serveur, est ok si vous l'automatisez. Lorsque vous apportez des modifications à votre code d'application, cela vous rendra les choses très difficiles. À un certain moment, vous allez faire des allers-retours, apporter des modifications au code et les tester sur le serveur ... puis oublier de réinitialiser vos permissions de fichiers/répertoires en lecture seule.

Si vous n'avez qu'un seul compte d'utilisateur sur votre machine de production, je m'en tiendrai aux autorisations par défaut - les choses sont probablement gérées pour vous. Ou vous pouvez supprimer les autorisations de groupe et "autres", comme décrit ci-dessous.

Une configuration de production typique serait d'avoir un groupe d'applications auquel vous appartenez. Vous voulez également un utilisateur distinct pour exécuter votre application PHP. Conservez les autorisations complètes pour le propriétaire et le groupe et supprimez toutes les autorisations de "other".De cette façon:

• Les développeurs gardent leurs identifiants individuels - vous pouvez savoir qui a fait quoi quand.
• Vous et d'autres développeurs pouvez copier le nouveau code sur le serveur.
• L'application peut exécuter le code.
• L'application ne peut rien accéder en dehors du code.
• Aucun autre utilisateur ne peut voir votre code.

Je suppose que c'est le travail de quelqu'un d'autre de gérer votre serveur de production? Ils vont passer du temps à s'assurer que personne ne peut se connecter et fouiller. Alors que vous devez vous assurer que personne ne peut exécuter les commandes du système d'exploitation, je pense que le meilleur endroit pour commencer est d'en savoir plus sur xss. Les paramètres par défaut du serveur php devraient être corrects. La partie la moins sécurisée de l'application, est la partie que vous avez vu. Si quelqu'un doit accéder à un appel système, il est plus susceptible de passer par un formulaire. Même si vous éliminez les appels système, les formulaires sont toujours susceptibles de stocker du javascript. Sauf si vous stockez des cartes de crédit dans votre application, la cible la plus probable serait le mot de passe/session dans le navigateur de votre utilisateur.

Answer 2

Ce n'est pas plus sûr puisque PHP peut toujours faire chmod 777 même sur des fichiers chmodés (s'ils sont la propriété de PHP). Cependant, il est plus sûr car vous ne pouvez pas écrire ce fichier sans les chmoder auparavant.

Answer 3

chmod() est sur ma liste de PHP disable_functions.
Cela ne serait-il pas plus sûr?

L'utilisation de disable_functions permet de désactiver des fonctions spécifiques.
Si chmod() apparaît dans la directive disable_functions, il n'est pas plus sûr à utiliser; il est simplement désactivé, et le code PHP qui utilise chmod() déclenchera un avertissement.

La directive disable_functions ne doit pas être confondue avec les directives Safe Mode. disable_functions est actif même lorsque la directive safe_mode est définie sur 0; Lorsque safe_mode est activé, some functions sont désactivés ou limités. Pour noter que le mode sans échec est considéré comme obsolète, en PHP 5.3; Cela signifie que la directive est toujours acceptée en PHP 5.3, mais qu'elle ne peut plus être utilisée à aucun moment.

Answer 4

Désolé pour mon anglais.

Je pense à trois raisons possibles.

1. Vérifiez safe_mod drapeau dans votre php.ini, si safe_mod est ON vous obtenez peut-être quelques problèmes avec cette fonction.
2. Si vous avez plesk, vous rencontrez des problèmes si vous créez des dossiers ou des fichiers avec un autre utilisateur qui n'a pas été créé avec plesk.
3. Il est probable qu'il vous manque une bibliothèque php.