Dicas de Segurança em PHP

1) Cuidado ao utilizar arquivos “.inc”.

Muitos programadores preferem usar arquivos “.inc” para identificar arquivos que são chamados através das funções include() e require() (e as respectivas “_once”).

Se você não configurar o servidor Apache corretamente, os arquivos “.inc” podem ser baixados e lidos, ao invés de interpretados pelo servidor. O resultado é seu código-fonte exposto. Em casos mais graves, arquivos de configuração, que incluem a senha do banco de dados, podem ser lidos por qualquer um.

Detalhe, isto é mais comum do que se pensa. Digite no Google: filetype:inc mysql_connect e você verá que muitos sites, além de não configurarem o arquivo .inc corretamente, mantém a listagem de arquivos e pastas disponível. Essa busca retornará arquivos que terminam com “.inc” e possuem a palavra “mysql_connect”, que é uma função para conectar ao banco de dados, que tem como argumentos o endereço, usuário e senha. Logo, é possível obter todos os dados necessários para conectar-se ao banco de dados.

Código para o Apache interpretar arquivos .inc como .php:

(adicionar ao arquivo .htaccess) Código PHP:

*Pode não funcionar em hospedagem compartilhada, verifique antes.

2) Listagem de Arquivos e Pastas. Evite curiosos e problemas bloqueando a listagem de arquivos.

Poucas vezes, a listagem de arquivos de uma pasta pode ser útil. Portanto, se você necessita realmente usar a listagem de arquivos e pastas, faça um script em PHP. Com ele, você pode definir quais pastas / arquivos serão exibidos. Desabilitando a listagem de arquivos e pastas, você evita que os buscadores fucem em seu site e indexe arquivos desnecessários. Lembre-se bem que existem buscadores inofensivos, como o Googlebot e Yahoo/Slurp, mas também existem buscadores maliciosos, como o DataCha0s.

Código para o Apache não ler os arquivos:

(adicionar ao arquivo .htaccess) Código PHP:

3) Magic_Quotes on? Muito cuidado ao portar o código.

Posso dizer que com a diretiva Magic_Quotes ligada, praticamente somem os ataques SQL Injection nos sites rodando PHP. Esta diretiva escapa com uma \ dados enviados via GET POST e COOKIE automaticamente.

É muito comum ter esta diretiva ligada em sites que não precisam de performance ao máximo ou servidores compartilhados. Enquanto é um bom recurso para iniciantes, pois dispensa o uso da função addslashes() ao fazer consultas SQL, uma necessidade de portar o código pode levar a riscos sérios.

Imagine se você desenvolve um sistema online para um cliente: seu servidor utilizar Magic_Quotes on enquanto o da empresa Magic_Quotes off. Você não faz nenhum tratamento específico para escapar as variáveis, deixando o sistema totalmente vulnerável.

Não entenda pelo lado errado: Magic Quotes são ótimas para evitar injeções de SQL, mas lembre-se que trata-se de uma diretiva e não uma configuração obrigatória.

4)  Nunca confie no HTML. Cuidado especial com formulários.

Se você criar um campo de formulário <input> com a propriedade maxlength=10, isto não quer dizer que todos os dados que forem passados através dele terão, no máximo, 10 caracteres. Isto pode ser facilmente alterado via javascript ou por ferramentas do browser (como o Dom Inspector, no Firefox).

Código de exemplo:

login.html

Código HTML:

<form name=”login” action=”identifica.php” method=”post”>

<input type=”text” name=”nome” maxlength=10>

<input type=”password” name=”senha” maxlength=1

</form>

identifica.php

Código PHP:

<?php

$nome = $_POST[‘nome’]; //recebe o nome

$senha = $_POST[‘senha’]; //recebe a senha

//Verifica se o nome e senha são maiores do que o permitido pelo site if (

(strlen($nome) > 10 )

|| (strlen($senha) > 12)

) {

die(“Eu, estou, protegido. Um abraço e boa tentativa.”);

}

?>

Atenção especial: Cuidado ao armazenar valores no campo <input type=”hidden”>. Procure encriptar o que for necessário. Assim como os demais comandos HTML, os valores desta são facilmente editáveis

5) Validação Javascript. Útil, mas se, e somente se, for implementada JUNTO com a validação server-side.

A validação com Javascript pode ser útil para evitar que o usuário tenha que ficar processando mil vezes uma página ao preencher de maneira inválida. Porém, não podemos somente usar o Javascript para validar, até porque existem browsers que sequer funcionam com Javascript. Nesses browsers, nenhum dado seria validado e isto é perigoso. Nunca se esqueça que o Javascript é client-side, logo, pode ser manipulado pelo computador cliente.

6) Manipular arquivos é útil, mas tome os devidos cuidados.

Às vezes, precisamos ler, fazer o download ou adicionar informações a um arquivo. Nada melhor que usar readfile(), fopen() e as demais funções necessárias. O cuidado deve estar nos argumentos que você passar. Exemplo de código mal-feito:

Página ler.php

Tudo funciona bem – bem inseguro.

Exemplo: Acessando o link abaixo, o site escreverá todo o código fonte. http://www.exemplo.com/download/ler.php?arquivo=ler.php

Isso fica EXTREMAMENTE perigoso se utilizarem comandos para subir e descer diretórios.Exemplo:

http://www.exemplo.com/download/ler….o=../.htaccess

Logo, o caminho seria, por exemplo,: /home/exemplo/www/.htaccess

Em teoria, é possível acessar qualquer conteúdo do site, desde que se conheça a estrutura do mesmo e tenha permissão para tal.

Se você só for ler arquivos na mesma pasta, utilize str_replace(), para remover “..” e “/”. Caso contrário, faça a devida programação para evitar problemas. Por exemplo, permita a leitura somente dos arquivos necessários, através da extensão, por exemplo.

Obs: Este tópico também se aplica à função highlight_file() / show_source()

7) Retorno de informações mal-feito pode levar a HTML Injection.

O usuário faz uma busca por “uidroot” em seu site. O seu site retorna “Não foi possível encontrar ‘uidroot’. Tente outra palavra “.

E se o usuário busca por “<b>uidroot”? Se você não tratar corretamente o retorno, verá o site exibindo:

“Não foi possível encontrar ‘uidroot’ Tente outra palavra.”.

Muitas pessoas ignoram o HTML Injection, alegando que é só um problema estético. Para os usuários do Orkut: em meados de Agosto / Setembro de 2006, houve um problema grave de HTML Injection na página de recados, que permitia que uma pessoa injetasse HTML (imagens, videos, javascript etc) na página de recados de qualquer pessoa. Enquanto alguns acharam engraçado postar imagens, outros usaram os recursos em Javascript para redirecionar à paginas falsas de login, capturar dados, download de arquivos automaticamente e muito mais. O mais agravante foi que para usar o Orkut, você precisa de Javascript, portanto, a taxa de usuários afetados chegaria a até 99%, lembrando que existem usuários que bloqueiam o javascript quando ele vem de uma domínio diferente ao acessado. Felizmente, o Orkut corrigiu em alguns dias, evitando a catástrofe.

Escape corretamente os comandos HTML. Se não precisar exibir código HTML, utilize a função strip_tags().

E cuidado com o Cross-Site Scripting (o famoso XSS), utilizado com a injeção da tag <iframe> para roubo de cookies e posterior roubo de sessão se o programador não fizer um sistema seguro de sessões.

8) Portais Prontos.

Caso você utilize algum portal pronto como PHP-NUKE, JOOMLA, DRUPAL, WORDPRESS,

OSCOMMERCE e alguns outros do tipo, fique atento as atualizações sobre novas versões e atualizações de módulos adicionais para evitar problemas como a invasões por vulnerabilidades encontradas nesse tipo de aplicação.

9) Permissão de escrita total.

Cuidado ao dar permissão total de escrita para arquivos e pastas, com uma permissão total de escrita, muitos usuários mal intencionados poderão procurar por essa falha e estarem tentando algum médoto de invasão, com escrita na pasta ou alteração do arquivo onde possuem permissão de total.

10) Cuidado com session.

Caso você utilize session em seu sistema, tenha cuidado se ela não fica exposta para qualquer usuário, pois é possível um usuário mal intencionado estar “roubando” uma session aberta e estar efetuando login sem estar devidamente cadastrado no sistema.