Seguraça Acesso PHP

O propósito deste texto é informar aos programadores PHP dos erros comuns em segurança que podem ser encontrados em scripts PHP. Enquanto muitos dos seguintes conceitos podem parecer ser um senso comum, eles infelizmente não são sempre uma prática comum.

Após aplicar as seguintes técnicas ao seu código, você estará apto a eliminar a grande maioria dos furos de segurança que povoam muitos scripts. Muitos destes furos de seguranças foram encontrados em scripts PHP comerciais e open source largamente utilizados no passado (cito o OsCommerce, o WordPress e o phpBB como exemplos).

O mais importante conceito a aprender neste artigo é que você nunca deve confiar que o usuário entrará com dados exatamente como era esperado. A forma como a maioria dos scripts PHP são comprometidos é entrando com dados inesperados para explorar furos de segurança inadvertidamente deixados no script.

Usuários e Senhas

Outro ponto muito importante é não exibir, em momento algum, o nome de login (usuário) de algum usuário cadastrado no sistema. Lembre-se que para um usuário conseguir invadir a conta do outro ele precisa de duas coisas: usuário (ou e-mail) e a senha.. Se ele souber o usuário já tem 50% de sucesso.

Vale lembrar também que você não precisa deixar a senha do usuário na forma real quando salva-la no banco. É muito mais seguro salvar um md5() ou sha1() da senha no banco e quando for necessário fazer a validação do usuário você também gera o md5() ou sha1() da senha que ele digitou e compara com o que há no banco. Assim, se por ventura alguém conseguir invadir e pegar todos os registros do banco de usuários, o máximo que ele irá conseguir são o usuário/e-mail e uma senha criptografada.

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:

Addtype application/x-httpd-php .inc

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:

Options -Indexes

Magic_Quotes on?

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.

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).

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.

Validação Javascript

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.

Manipular