Insegurança comum na configuração do PHP?

Eu trabalho com a administração de sistemas em uma universidade e apenas me deparei com algo que provavelmente é comum, mas foi um choque para mim.

Todos os diretórios public_html e áreas da web são armazenados em afs, com permissões de leitura para os servidores da web. Como os usuários podem ter scripts php em public_html, isso significa que eles podem acessar os arquivos uns dos outros a partir do php (e os principais arquivos da web!).

Isso não apenas torna totalmente inútil a proteção por senha .htaccess, como também permite que os usuários leiam arquivos de origem php contendo senhas do banco de dados mysql e informações sensíveis semelhantes. Ou, se descobrirem que outras pessoas têm diretórios nos quais os servidores da Web têm acesso de gravação (por exemplo, para registros pessoais ou para salvar dados de formulários enviados), eles podem armazenar arquivos nessas contas.

Um exemplo simples:

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

Isso é um problema comum? E como você normalmente resolve isso?

ATUALIZAR:

Obrigado pela contribuição. Infelizmente, parece que não há uma resposta simples. Em um grande ambiente compartilhado como esse, provavelmente os usuários não devem ter tanta escolha. A melhor abordagem que posso pensar é definir "open_basedir" na configuração principal de todos os diretórios "public_html", executar o suphp e permitir apenas php limpo (sem scripts cgi, executando comandos externos com backticks etc.).

Mudar a política como essa quebraria muitas coisas e possivelmente faria com que os usuários pegassem seus forcados e nos perseguissem ... Vou discutir isso com meus colegas e atualizar aqui se tomarmos uma decisão sobre como alterar a configuração.

Pode-se usar o suphp, que executa o script php com o uid de seu proprietário.

http://www.suphp.org

Minha sugestão seria limitar o acesso do PHP aos arquivos (por meio de open_basedirdiretivas semelhantes, por host): Você deseja que os usuários possam abrir / ler / gravar arquivos em sua raiz da web e, talvez, um nível acima dela (para rascunho espaço), mas não um diretório onde estariam armazenando, por exemplo, htpasswdarquivos.

Uma estrutura de diretórios como:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Atenderia a esse requisito: open_basedirpoderia ser apontado com /Client/sitesegurança e os htpasswdarquivos armazenados /Client/auth(com .htaccessarquivos ou httpd.confmodificados para apontar para o local apropriado).
Isso evita que seus clientes abram arquivos de outras pessoas, e, como benefício, usuários mal-intencionados não conseguem ler as coisas /Client/auth(ou qualquer outra coisa no seu sistema, como /etc/passwd:-)

Veja http://php.net/manual/en/ini.core.php para mais detalhes sobre a implementação open_basedir e per-vhost.

Não, não é um problema comum, porque a maioria dos hosts compartilhados definiria uma configuração open_basedir no arquivo htaccess no diretório public_html de cada usuário (ou no vhost se cada usuário tiver seu próprio vhost).

por exemplo, do arquivo .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

Mas certifique-se de definir as permissões corretas no arquivo .htaccess para impedir que o usuário altere o open_basedir (se eles tentarem substituí-lo no subdir / .htaccess, ele não funcionará - mas você provavelmente deve testá-lo) .

HTH

C.

O AFS ignora permissões simples de usuário unix. O suPHP executa um setuid antes de executar o programa php, mas isso não fornece ao processo os tokens kerberos necessários para acessar o AFS e fica restrito às suas permissões. O suPHP precisaria ser modificado de alguma maneira para obter esses tokens antes que ele pudesse se apresentar ao sistema AFS como esse usuário. Até onde eu sei, isso não foi feito. (Na verdade, eu encontrei essa pergunta ao procurar se alguém havia feito isso.)