Protegendo servidores web PHP

Question

As aplicações PHP têm uma reputação de problemas de segurança superiores à média. Quais técnicas de configuração você usa para garantir que o aplicativo seja seguro possível?

Estou procurando ideias como:

• Usando Hardened PHP / Suhosin
• Usando o mod_security
• Desativando register_globals e allow_url_fopen no php.ini

Eu normalmente uso o Linux, mas fique à vontade para sugerir soluções Windows também.

    

Answer 1

1. Use a diretiva open_basedir para restringir seus scripts PHP ao diretório inicial e a eventuais diretórios de aplicativos extras. Isso é muito eficiente por si só.

2. Use php endurecido porque isso não custa nada e pode ajudar.

3. Use suPHP para executar scripts PHP como o proprietário do arquivo (um usuário por site) e evite usar arquivos com permissões ruins, como o 777 ... suPHP também pode permitir que você tenha em php.ini por site, de modo que o requisito estúpido de um site não destrua tudo.

4. O Mod_security é uma grande vantagem, mas precisa ser bem usado e configurado.

Answer 2

Na minha experiência, a maioria das vulnerabilidades em um site baseado em PHP é o resultado de um design (site) ruim, em vez de falhas no próprio PHP.

Algumas dicas rápidas:

• Entrada de filtro Universally , saída de escape. Clarificaiton: filter não significa escape, significa "se eu encontrar algo suspeito nesta entrada do usuário, faça com que o envio falhe e diga ao usuário para reformatar."
• Em vez de usar escapeshellcmd (), simplesmente não permite que nenhuma entrada do usuário seja executada no shell . Isso é perigoso e provavelmente nunca é realmente necessário.
• Não chame funções como phpinfo () em um site de produção (ou, se fizer, veja abaixo *).
• Ao projetar um aplicativo da web, sempre considere "este é um possível vetor de ataque?" Diga, injeção de SQL. Se a resposta for "sim", conecte-a imediatamente - não diga "ok, adicionarei isso mais tarde no desenvolvimento como um recurso". A segurança nunca é um recurso.
• Nunca gera erros brutos para o usuário; isso significa definir display_errors do php.ini = Off, log_errors = On. Arraste erros de tempo de execução e imprima algo bonito. Pegue a baleia do Twitter como um exemplo: ela não dará ao usuário informações sobre o nível de depuração, apenas diz "woops, algo quebrou, por favor atualize".

* Você também pode dar uma olhada em um post curto que eu escrevi chamado "Securing phpinfo (), tipo de" e não se esqueça de ler os comentários link Foi uma idéia rápida que tive que (de certa forma) proteger o phpinfo () se de alguma forma eu esquecesse de removê-lo em um site de produção.

De uma maneira mais geral, alguns desenvolvedores escrevem wrappers para funções sensíveis que verificam se o sinalizador "site de produção" está configurado ou não e desativa a função sensível em produção.

    

Answer 3

Outros parâmetros que devem ser alterados para endurecer o PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Armazena todos os erros do PHP no arquivo /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

    

Answer 4

Adicionei os repositórios dotdeb ao meu /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Como eles corrigem php / apache / mysql com muito mais frequência que o Debian.

    

Answer 5

Considere configurar open_basedir em uma base "por site". open_basedir é uma configuração do php.ini que impede que seus scripts acessem arquivos fora de uma lista branca definida. Se o seu servidor hospeda vários sites, ele impedirá que um site leia as configurações do banco de dados de outro site. Isso também impedirá que um script php acesse / modifique os arquivos principais do sistema. Open basedir é fácil de configurar, basta adicionar a linha " php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list " a cada vache do Apache.

Considere também desativar o mecanismo de script PHP para todos os sites / pastas que não devem conter scripts PHP (por exemplo, uma pasta de imagens carregadas). Novamente, isso é simples, adicione "php_admin_value engine off" a qualquer Apache VirtualHosts que não precise de php. Para desativar o PHP em um diretório, coloque a mesma coisa em uma tag do Directory.

Execute as permissões de arquivo o mais tight possível, evite o acesso de gravação aos scripts PHP para o usuário do Apache, isso impede que um script em execução se modifique ou a outros scripts no mesmo site / servidor. Evite 777 permissões, se possível, calcule as permissões mínimas necessárias para executar o aplicativo e usá-las.

Se você estiver hospedando vários sites, cada um com seu próprio banco de dados, use um usuário MySQL / Postgres separado para cada um e defina permissões em cada usuário de forma que eles tenham acesso somente aos bancos de dados relevantes. Novamente, isso evitará que um script não autorizado altere o banco de dados de outro aplicativo.

Suosin, HardenedPHP, mod_security e similares também são valiosos, mas use-os em adição a uma configuração tight locked, não em vez de.

    

Answer 6

Suhosin tem um custo de performance bastante substancial, então o comentário "nothing costs" está um pouco errado.

    

Answer 7

Você está procurando algumas sugestões básicas de firewall / topologia? Eu gosto da idéia de usar coisas como pound para impedir o acesso diretamente ao servidor web do PHP a partir dos internets não lavados. Dessa forma, você também pode segregar o servidor da Web de outras partes da sua rede.

    

Answer 8

Usar Suhosin / mod_security / SuPHP certamente tornará seu servidor PHP seguro. Desativar certas funções como exec, passthru, system e escapeshellcmd ajudará muito também.