Insécurité de configuration PHP courante?

Je travaille avec l'administration des systèmes dans une université et je suis juste tombé sur quelque chose qui est probablement commun, mais qui a été un choc pour moi.

Tous les répertoires public_html et les zones Web sont stockés sur afs, avec des autorisations de lecture pour les serveurs Web. Étant donné que les utilisateurs sont autorisés à avoir des scripts php dans leur public_html, cela signifie qu'ils peuvent accéder aux fichiers des autres depuis php (et les principaux fichiers Web!).

Non seulement cela rend toute protection par mot de passe .htaccess complètement inutile, mais cela permet également aux utilisateurs de lire des fichiers source php contenant des mots de passe de base de données mysql et des informations sensibles similaires. Ou s'ils découvrent que d'autres personnes ont des répertoires où les serveurs Web ont un accès en écriture (par exemple pour les journaux personnels ou pour enregistrer les données de formulaire soumises), ils peuvent stocker des fichiers dans ces comptes.

Un exemple simple:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

Est-ce un problème courant? Et comment le résolvez-vous généralement?

METTRE À JOUR:

Merci pour la contribution. Malheureusement, il semble qu'il n'y ait pas de réponse simple. Dans un grand environnement partagé comme celui-ci, les utilisateurs ne devraient probablement pas avoir autant de choix. La meilleure approche à laquelle je peux penser est de définir "open_basedir" dans la configuration principale pour tous les répertoires "public_html", d'exécuter suphp et de n'autoriser que le php propre (pas de scripts cgi, exécution de commandes externes avec des astuces, etc.).

Changer la politique comme ça casserait beaucoup de choses cependant, et inciterait très probablement les utilisateurs à saisir leur fourche et à nous poursuivre ... J'en discuterai avec mes collègues et je mettrai à jour ici si nous décidons comment changer la configuration.

On peut utiliser suphp qui exécute le script php avec l'uid de son propriétaire.

http://www.suphp.org

Ma suggestion serait de limiter l'accès de PHP aux fichiers (via open_basedirdes directives similaires, sur une base par hôte): vous voulez que les utilisateurs puissent ouvrir / lire / écrire des fichiers sous leur racine Web, et peut-être un niveau au-dessus (pour zéro espace), mais pas un répertoire où ils seraient par exemple stocker des htpasswdfichiers.

Une structure de répertoires comme:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Répondrait à cette exigence: open_basedirpourrait être pointé en /Client/sitetoute sécurité et les htpasswdfichiers stockés dans /Client/auth(avec des .htaccessfichiers ou httpd.confmodifiés pour pointer à l'emplacement approprié à la place).
Cela empêche vos clients d'ouvrir les fichiers de quelqu'un d'autre ET, comme avantage, les utilisateurs malveillants ne peuvent pas lire le contenu /Client/auth(ou quoi que ce soit d'autre sur votre système, comme /etc/passwd:-)

Voir http://php.net/manual/en/ini.core.php pour plus de détails sur l'implémentation open_basedir et per-vhost.

Non, ce n'est pas un problème commun car la plupart des hôtes partagés définiraient une configuration open_basedir dans le fichier htaccess du répertoire public_html de chaque utilisateur (ou dans le vhost si chaque utilisateur a son propre vhost).

par exemple du fichier .htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Mais assurez-vous de définir les bonnes autorisations sur le fichier .htaccess pour empêcher l'utilisateur de modifier l'open_basedir (s'il essaie de le remplacer dans subdir / .htaccess, cela ne devrait pas fonctionner - mais vous devriez probablement le tester pour vous en assurer) .

HTH

C.

AFS ignore les autorisations utilisateur Unix simples. suPHP exécute un setuid avant d'exécuter le programme php, mais cela ne donne pas au processus les jetons Kerberos nécessaires pour accéder à AFS et être limité à ses autorisations. suPHP devrait être modifié d'une manière ou d'une autre pour obtenir ces jetons avant de pouvoir se présenter au système AFS en tant qu'utilisateur. Pour autant que je sache, cela n'a pas été fait. (En fait, j'ai trouvé cette question en cherchant à voir si quelqu'un d'autre l'avait fait.)