Os 6 requisitos mínimos
por Er Galvão Abbott (http://www.galvao.eti.br/) na revista PHPMagazine (http://www.phpmagazine.com.br/)
Apresentareremos neste artigo 6 requisitos que todo o desenvolvedor PHP deveria contemplar em sua aplicação. São boas práticas e hábitos simples que implementam um nível mínimo de segurança em qualquer sistema ou ferramenta desenvolvida com a linguagem.
A linguagem PHP é, sem dúvida, uma das mais populares quando o assunto é desenvolvimento de aplicações web. Existe, porém, um preconceito muito grande com a linguagem quando a questão é segurança. Neste artigo veremos 6 requisitos básicos que toda aplicação deveria possuir e que implementarão o mínimo de segurança em tudo o que você desenvolver.
Conceito: PHP é uma linguagem mais vulnerável do que as outras?
Atualmente impera no mercado de desenvolvimento um preconceito relacionado à segurança de aplicações PHP. A linguagem é freqüentemente alvo de duras críticas por parte da própria comunidade de desenvolvimento, e não é raro presenciarmos aplicações extremamente vulneráveis que, com toda a certeza, dão razão a essas críticas.
Este preconceito, totalmente equivocado, tem suas origens na extrema flexibilidade de configuração e uso da linguagem e no número cada vez maior de desenvolvedores inexperientes que começam sua carreira desenvolvendo aplicações PHP, ignorando questões básicas, seja por falta de conhecimento ou porque estão procurando agilizar sua produção pessoal.
Este artigo não é destinado apenas aos que estão começando. É surpreendente o número de desenvolvedores mais experientes que, por terem adquirido vícios, ainda ignoram as questões que apresentaremos aqui.
Requisito #1: Esqueça register_globals!
Register_globals é, sem dúvida alguma, a diretiva de configuração mais popular e polêmica já implementada no PHP. É popular entre os desenvolvedores por tornar o processo de programação muito mais ágil e prático. É polêmica porque retira tanto do programador quanto do interpretador da linguagem a responsabilidade em definir a origem das informações utilizadas pela aplicação.
Esta diretiva causou tantos problemas que começou a vir desabilitada por default a partir da versão 4.2.0 e será eliminada na versão 6. Por isso, se você ainda programa com register_globals ligada, está mais do que na hora de mudar.
Observe o seguinte exemplo de código:
$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$autenticado) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}
Este código verifica por uma variável booleana chamada $autenticado, que tipicamente viria de uma sessão aberta quando o usuário se autenticou em nossa aplicação ou mesmo de um cookie. Ao utilizarmos os recursos da register_globals, porém, não estamos dizendo ao interpretador PHP que este dado deve vir obrigatoriamente de uma destas duas fontes.
Sendo assim, o interpretador procurará por esta variável em diversas fontes (variável do servidore web, dados de formulário, cookie, arquivos enviados por upload, query string ou sessões) das quais ele obteve informações até encontrá-la, desprezando se esta fonte está correta.
Torna-se extremamente simples “enganar” a sua aplicação PHP, basta que eu chame o seu arquivo passando a variável esperada por query string.
http://www.meusite.com.br/script.php?autenticado=1
Ao receber a query string contendo a informação “autenticado”, este dado será automaticamente interpretado como uma variável pelo interpretador, quer exista sessões ou cookies ou não.
Uma dúvida freqüente é “se não tenho autorização para desligar a register_globals o que eu posso fazer?”. A resposta para isso é tão simples quanto tudo o mais na linguagem: programe como se ela estivesse desligada! Veja como fica o nosso código ao não utilizar a register_globals:
$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$_SESSSION['autenticado']) {
header(”Location: $url?erro=$errMsg”);
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}
Observe a mudança: ao utilizarmos o array super global $_SESSION, estamos explicitando para o interpretador que a informação “autenticado” tem que, obrigatoriamente, vir de uma sessão. Isto significa que será impossível para o interpretador confundir este dado com um dado enviado pela query string, pois este fica armazenado em um array super global diferente:
- $_SERVER - Informações definidas pelo servidor web (Apache, IIS etc)
- $_GET - Informações passadas por query string ou por um formulário web utilizando o método GET
- $_POST - Informações enviadas, tipicamente, por um formulário web utilizando o método POST
- $_COOKIE - Informações fornecidas por um cookie HTTP
- $_FILES - Informações fornecidas por arquivos que foram enviados via upload HTTP
- $_ENV - Informações fornecidas pelo ambiente do servidor
- $_REQUEST* - Informações fornecidas por GET, POST ou COOKIE
* Cuidado: O uso do array super global $_REQUEST é quase tão perigoso quanto a register_globals em si, pois nesse caso a informação pode vir de qualquer um dos 3 métodos: GET, POST ou COOKIE.
Requisito #2: Use require e não include
O comando include e seus derivados - como include_once - são freqüentemente usados em detrimento do comando require. Este fato curioso a princípio é conseqüência da similaridade do comando include com outras linguagens, como C e Java.
O que muita gente não sabe, porém, é que este comando carrega consigo um risco muito grande para sua aplicação: se por algum motivo a inclusão do arquivo falhar - erro de digitação, disco corrompido etc - será gerado um erro de nível warning, um nível leve de erro que não causa a parada da execução do script.
Utilizando o comando require, garantimos que, no caso de falha na carga do arquivo, seja gerado, além do erro de nível warning, um erro de nível fatal. Em bom português isso significa que a execução do seu script será imediatamente interrompida neste caso. Por que é bom que seu script seja interrompido no caso de falha de inclusão de outro arquivo? Simples: no caso de falhas, as variáveis, as funções, as constantes e o que mais este arquivo carregava consigo, simplesmente, não estarão disponíveis.
Requisito #3: Filtre a entrada de dados!
Um dos principais conceitos de segurança é a filtragem dos dados que são recebidos antes de utilizá-los. A falta de fitlragem é a causa de inúmeros problemas de segurança, incluindo o infame SQL Injection, ou Injeção de SQL. Observe o seguinte código:
require_once("conecta.php");
$conn = conecta();
$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . ‘<br />’;
}
mysql_close();
O problema deste código é utilizar um dado informado pela query string (uid) sem fazer nenhuma filtragem, ou seja, nosso script aceitará cegamente qualquer coisa que for digitada como valor de uid. Observe a seguinte URL:
http://www.meusite.com.br/script.php?uid=198%20OR%20′x’='x’
Após a conversão dos caracteres especiais desta URL, o valor de uid será (sem aspas duplas): “198 or ‘x’='x’”. Note que, quando concatenarmos isto à nossa query, ela terá sofrido uma grande modificação:
SELECT email FROM usuarios WHERE usuario_id = 198 or ‘x’='x’
É por isso que a chamamos de “Injeção de SQL”. A parte em vermelho acima é formada de SQL válido, mas completamente alienígena à nossa plicação: ele modifica o comportamento original da query.
Observe que, com um mínimo de esforço, um usuário conseguiu expor todos os e-mails cadastrados em nossa base de dados: como foi utilizado o operador “OR” e a segunda condição (’x'=’x') é sempre verdadeira, serão exibidos todos os registros.
Para evitarmos este tipo de problema, devemos aplicar um tratamento à informação antes de utilizá-la. Caso a minha query - como neste exemplo - esteja esperando um número inteiro, a solução é simples: forçamos a conversão do dado recebido para número inteiro:
require_once("conecta.php");
$conn = conecta();
settype($_GET['uid'], integer);
$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . ‘<br />’;
}
mysql_close();
A partir de agora, qualquer dado enviado pela query string será primeiro convertido para inteiro e somente depois desta conversão é que o utilizaremos. No caso de uma tentativa de Injeção de SQL, nosso script considerará apenas a parte numérica (198), como deveria ser. Além disso, se por um acaso nosso script receber apenas texto, a função settype converterá isto para o número 0.
Caso a minha query esteja esperando uma string a solução reside em criar um tratamento que valide esta string. Vejamos um exemplo: possuo uma query que busca dados de um usuário através de seu endereço de e-mail:
$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . “‘”;
Sabemos que um endereço de e-mail é formado por um nome de usuário, uma arroba e um domínio. Para fins de simplificação do exemplo, trabalharemos como se o usuário só pudesse usar letras, números e o caracterese de ponto - para quem levar a validação de e-mail a sério consulte a RFC 822. Podemos representar isso através de uma expressão regular:
/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/
Sendo assim, só aceitaremos o dado de endereço de e-mail se ele estiver dentro dos padrões de minha expressão regular. Nosso código então ficaria assim:
require_once("conecta.php");
if (preg_match('/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/’, $_GET['email'])) {
$conn = conecta();
$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . “‘”;
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . ‘<br />’;
}
} else {
die(”O dado informado não é um endereço de e-mail válido.”);
}
mysql_close();
Requisito #4: Sem erros para o usuário
Falaremos aqui de outro ponto importantíssimo na questão de segurança que é freqüentemente ignorado pelos desenvolvedores: as mensagens de erro.
As mensagens de erro foram feitas para que o desenvolvedor possa trabalhar de forma mais prática e descobrir o que ele está fazendo de errado. Observem, entretando, que, quando uma aplicação atinge maturidade suficiente para “entrar em produção”, torna-se imperativo que o usuário não visualize mensagens de erro.
A razão disso é muito simples: as mensagens de erro freqüentemente trazem informações sensíveis. Observe como exemplo uma típica mensagem de falha de conexão com a base de dados:
Warning: mysql_connect() [function.mysql-connect]:
Access denied for user ‘foo‘@’localhost‘ (using password: YES)
in /usr/local/apache/htdocs/script.php on line 2
Note, através das partes destacadas, que esta mensagem me informa:
- O tipo de RDBMS: mysql
- O usuário de conexão com a base: foo
- Que este usuário está tentando uma conexão de dentro do servidor: localhost
- O caminho absoluto da raiz web: /usr/local/apache/htdocs
- O nome do script: script.php
É por isso que, quando colocamos uma aplicação em produção, ocultamos as mensagens de erro e as gravamos diretamente em um arquivo de log. Isto é muito simples de implementar:
- Desative a diretiva de configuração display_errors
- Ative a diretiva log_errors
- Indique o caminho absoluto do arquivo de logs na diretiva error_log
Exemplo:
display_errors = Off
log_errors = On
error_log = /log/php_errors.log
Requisito #5: Esconda do servidor web o que ele não precisa acessar
Quantos de nós não usamos em nossas aplicações um arquivo, tipicamente chamado de config.php ou setup.php, onde guardamos, por exemplo, usuário e senha da base de dados?
Não há nada de errado nisso, mas cuidado: se este arquivo não gera saída de informação em HTML, por que deixá-lo acessível via web?
Para esclarecermos o problema, vamos definir 3 coisas:
- minha raiz web é: /usr/local/apache/htdocs
- meu arquivo de configuração fica localizado em /usr/local/htdocs/config/config.php
- este é um código típico que usa este arquivo:
require_once("/urs/local/htdocs/config/config.php");
/* bla bla bla */
Observe que o erro neste caso é confundir interpretador PHP e servidor web. O Apache (ou IIS, Xitami etc) não precisa saber onde está este arquivo. Isto é responsabilidade do interpretador.
Outro problema é que se arquivo fica desnecessariamente exposto, afinal de contas basta eu abrir um navegador e digitar:
http://www.meusite.com.br/config/config.php
Não faz sentido. Por mais que você possa argumentar que não há forma de ler o código-fonte deste arquivo, ainda assim, isto não muda o fato de que ele está desnecessariamente exposto.
A solução é simples: movemos o arquivo para fora da raiz web:
/usr/local/config/config.php
E depois apenas acertamos as permissões e corrigimos nosso código:
require_once("/urs/local/config/config.php");
/* bla bla bla */
A partir de agora nosso arquivo de configuração só pode ser lido por quem precisa dele: o interpretador PHP.
Requisito #6: Use criptografia
Dados sigilosos são chamados assim por um motivo. Quando tratamos especificamente de senhas é impressionante a quantidade de aplicações web que gravam senhas em texto puro na base de dados.
Ora, se a senha possui a importância que tem e quem a escolhe é o usuário, por que alguém mais precisa ler essa senha?
Se a senha possui este peso em nossa aplicação, não podemos nos dar o luxo de fazer com que ela trafegue pela aplicação totalmente exposta.
PHP implementa criptografia de várias formas, mas eu sugiro - para quem puder usar, pois exige instalação e configuração extra - a utilização da função mcrypt.
Os hashes MD5 e SHA-1 são opções válidas, mas o problema é a sua fragilidade: para o MD5 existe até dicionário de dados, enquanto o SHA-1 foi recentemente “quebrado” por um pesquisador chinês.
Conclusão
A implementação de regras básicas de segurança depende apena da boa vontade do desenvolvedor. Você deve ter percebido como a maior parte das soluções aqui apresentadas significam simples mudanças de hábito.
É mais do que tempo de nós, desenvolvedores PHP, deixarmos de lado nossos antigos vícios e começarmos a implementar boas práticas de programação.
Ganha o profissional, ganha a sua aplicação, ganha o seu cliente, ganha o mercado. Só quem perde nessa situação é quem tenta se aproveitar de nossa aplicação.
Referências e links sugeridos
[PHP Security Consortium] - http://phpsec.org/
[PHP RS] - http://www.phprs.com.br/
Er Galvão Abbott trabalha há mais de dez anos com programação de websites e sistemas corporativos com interface web. Autodidata, teve seu primeiro contato com a linguagem HTML em 1995, quando a internet estreava no Brasil. Atualmente, além de lecionar em diversos cursos, tem se dedicado ao desenvolvimento de sistemas baseados na web, tendo nas linguagens PHP, Perl e JavaScript suas principais paixões.
