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

Question

Eu trabalho com a administração de sistemas em uma universidade e me deparei com algo que é provavelmente comum, mas foi um grande 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 têm permissão para ter scripts php em seus public_html, isso significa que eles podem acessar os arquivos uns dos outros a partir do php (e dos principais arquivos da web!).

Isso não só torna a proteção de senha do .htaccess completamente inútil, como também permite que os usuários leiam arquivos de origem php contendo senhas do banco de dados mysql e informações confidenciais 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"); 
?>

Este é um problema comum? E como você costuma resolver isso?

ATUALIZAÇÃO:

Obrigado pela entrada. Infelizmente, parece que não há uma resposta simples. Em um grande ambiente compartilhado como esse, os usuários provavelmente não devem receber tanta escolha. A melhor abordagem que eu posso pensar é definir "open_basedir" na configuração principal para todos os diretórios "public_html", executar 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 ... Eu discutirei com meus colegas e atualizarei aqui se tomarmos uma decisão sobre como mudar a política. configuração.

    

Answer 1

Pode-se usar o suphp que executa o script php com o uid de seu dono.

link

    

Answer 2

Minha sugestão seria limitar o acesso do PHP aos arquivos (via open_basedir & diretivas semelhantes, em uma base por vamer): Você deseja que os usuários possam abrir / ler / gravar arquivos sob sua webroot e talvez um nível acima dele (para espaço de rascunho), mas não um diretório onde eles estariam armazenando, por exemplo htpasswd arquivos.

Uma estrutura de diretórios como:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Cumpriria este requisito: open_basedir poderia estar indicado em /Client/site com segurança e htpasswd arquivos armazenados em /Client/auth (com .htaccess arquivos ou httpd.conf modificados para apontar para o local apropriado).
Isso impede que seus clientes abram arquivos de outras pessoas E, como benefício, os usuários mal-intencionados não podem ler as informações em /Client/auth (ou qualquer outra coisa em seu sistema, como /etc/passwd : -)

Consulte o link para obter mais detalhes sobre o open_basedir & implementação por vhost.

    

Answer 3

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 evitar que o usuário altere o open_basedir (se eles tentarem sobrescrevê-lo no subdir / .htaccess, ele não deverá funcionar - mas você provavelmente deve testar isso para certifique-se).

HTH

C.

    

Answer 4

O AFS ignora as permissões de usuário unix simples. O suPHP executa um setuid antes de executar o programa php, mas isso não fornece ao processo os tokens do kerberos necessários para acessar o AFS e ficar restrito a suas permissões. O suPHP teria que ser modificado de alguma forma para obter esses tokens antes que ele pudesse se apresentar ao sistema AFS como aquele usuário. Tanto quanto sei, isso não foi feito. (Na verdade, encontrei essa questão quando procurei ver se alguém havia feito isso.)