Protegendo servidores Web PHP

Os aplicativos PHP têm uma reputação de problemas de segurança acima da média. Quais técnicas de configuração você usa para garantir que o aplicativo seja o mais seguro possível?

Estou à procura de ideias como:

• Usando PHP / Suhosin reforçado
• Usando mod_security
• Desabilitando register_globals e allow_url_fopen no php.ini

Eu normalmente uso Linux, mas sinta-se à vontade para sugerir soluções do Windows também.

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

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

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

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

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

Algumas dicas rápidas:

• Entrada de filtro universal , saída de escape. Esclarecimento: filtro não significa escape, significa "se eu encontrar algo suspeito nesta entrada do usuário, causar falha no envio e solicitar ao reformador".
• Em vez de usar escapeshellcmd (), simplesmente não permita 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 você o fizer, veja abaixo *).
• Ao projetar um aplicativo Web, sempre considere "esse é um vetor de ataque possível?" Digamos, injeção de SQL. Se a resposta for "sim", conecte-a imediatamente - não diga "ok, acrescentarei isso mais tarde no desenvolvimento como um recurso". Segurança nunca é um recurso.
• Nunca produza erros brutos para o usuário; isso significa definir display_errors = php.ini = Off, log_errors = On. Detecte erros de tempo de execução e produza algo bonito. Tome como exemplo a baleia do Twitter: ela não fornece ao usuário informações no nível de depuração, apenas diz "woops, algo quebrou, por favor atualize".

* Você também pode dar uma olhada em um pequeno post que escrevi chamado "Protegendo o phpinfo (), mais ou menos" e não deixe de ler os comentários http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Foi uma ideia rápida que eu tive que (de alguma forma) proteger o phpinfo () se de alguma forma me esqueci de removê-lo em um site de produção.

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

Outros parâmetros que devem ser alterados para proteger 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"

Armazene todos os erros de PHP no arquivo /var/log/phperror.log :

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

Adicionei os repositórios do 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 o php / apache / mysql com muito mais freqüência do que o Debian.

Considere a configuração open_basedir"por site". open_basediré uma configuração do php.ini que impedirá que seus scripts acessem arquivos fora de uma lista branca definida. Se o seu servidor hospedar vários sites, impedirá que um site leia as configurações do banco de dados de outro site. Também impedirá que um script php acesse / modifique os arquivos principais do sistema. O 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 host 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 do php. Para desativar o PHP em um diretório, coloque a mesma coisa em uma tag Directory.

Execute as permissões de arquivo o mais rígido possível, evite o acesso de gravação aos scripts PHP para o usuário Apache, isso impede que um script em execução se modifique ou 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 use-as.

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 deles e defina permissões para cada usuário, de modo que eles tenham apenas acesso aos bancos de dados relevantes. Novamente, isso impedirá que um script não autorizado adultere o banco de dados de outro aplicativo.

Suosin, HardenedPHP, mod_security e similares também são valiosos, mas use-os além de uma configuração bem fechada, não em vez de.

A suhosin tem um custo de desempenho bastante substancial, portanto o comentário "não custa nada" está um pouco fora.

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

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