O problema

Digamos que na página principal do nosso site, a gente tenha um formulário de login mais ou menos assim:

<form action="login.php" method="post">
Login: <input type="text" name="login" />
Senha: <input type="password" name="senha" />
<input type="submit" />
</form>

Um formulário bem simples. E para tratar este formulário, temos o login.php, que vai checar em um banco de dados se o login e a senha estão corretos, da seguinte forma (colocarei apenas o trecho com a consulta SQL relevante):

<?php
$sql = "SELECT * FROM usuarios WHERE login = '{$_POST['login']}' AND senha = '{$_POST['senha']}'";
$res = mysql_query($sql);
if (mysql_num_rows($res) > 0) {
    print "Login OK";
}
else {
    print "Login e senha não conferem";
}
?>

Ou seja, verificamos na tabela usuarios se temos uma linha com o login e a senha fornecidos. Caso essa consulta retorne alguma coisa, significa que existe uma linha com o login e a senha fornecidos, caso contrário, não existe.
Se no formulário eu preencho o login com “joe” e a senha com “xxxx”, a seguinte consulta SQL será montada e executada:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx'

Porém, o que acontece se eu preecher o formulário com o login = joe, e a senha com: xxxx’ OR true –
Neste caso, teremos a seguinte consulta:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx' OR TRUE --'

Essa consulta vai retornar todas as linhas do banco de dados (por causa do “OR true” no final), e como a checagem no código é se a consulta retornou mais de uma linha, estaremos logados.
Existem formas mais sofisticadas de proceder com este tipo de ataque, mas o foco do artigo é na defesa.

FIEO

FIEO é uma técnica bastante usada para aumentar a segurança dos aplicativos web. Significa “Filter Input/Escape Output”, ou traduzindo, “Filtre a Entrada/Escape a Saída”.
O primeiro passo é a filtragem da entrada, já que a regra número 1 da segurança em aplicativos web diz que não podemos jamais confiar em informações vindas de fontes externas. No nosso caso, poderíamos fazer a filtragem do login e da senha checando se eles possuem apenas caracteres permitidos. Por exemplo, o site poderia ter uma regra especificando que o login deve conter apenas letras e números. A filtragem então, poderia ser feita usando a função ctype_alnum():

<?php
if (!ctype_alnum($_POST['login'])) {
    die("login possúi caracteres inválidos");
}
?>

Se o FI do FIEO lida com a filtragem da entrada, o EO lida com a manutenção da saída no contexto em que for lida.
Ou seja, FI garante que a nossa entrada é valida, e EO garante que quem quer que receba os nossos dados, irá interpretá-los da forma correta.
No nosso caso, é importante que as aspas simples não sejam interpretadas como delimitadores na consulta SQL. E se eu quisesse ter uma senha que tivesse uma aspa simples no meio?
Existem 3 formas clássicas de se resolver este problema.

Forma 1: addslashes() no PHP

É a forma mais simples (e ingênua) de se tratar o problema. Por exemplo, se queremos nos proteger das aspas simples, poderíamos simplesmente escapá-las no PHP da seguinte forma:

<?php
$login = addslashes($_POST['login']);
$senha = addslashes($_POST['senha']);
?>

Dessa forma, caso uma aspa simples chegasse do usuário, seria devidamente escapada com uma “\” antes, e o servidor SQL não iria interpretá-la como um delimitador.
Para o nosso exemplo de ataque, resolveria.
O grande problema com esta solução é que ela só prevê ataques que usem aspas simples. Bancos de dados diferentes podem usar caracteres de controle diferentes, como aspas duplas, quebras de linha, ou outras coisas mais estranhas. E checar por todas estas formas é longe de ser a maneira mais eficaz (e viável!) de se proceder.
Temos uma outra opção, suportada por vários bancos de dados.

Forma 2: deixar o próprio banco escapar

A segunda opção é passar a string para o banco e deixar ele se virar. Afinal, ele sabe o que pode e o que não pode entrar em uma string. No MySQL, isso poderia ser feito da seguinte forma:

<?php
$login = mysql_real_escape_string($_POST['login']);
$senha = mysql_real_escape_string($_POST['senha']);
?>

Segundo a documentação, chamando esta função, o banco escapa automaticamente as seguintes sequencias: \x00, \n, \r, \, ‘, ” e \x1a. Ou seja, pelo visto as aspas simples não eram nosso único problema mesmo.
Existem funções semelhantes para outros bancos de dados (por exemplo, pg_escape_string() para o PostgreSQL).
Porém, a solução que considero mais elegante é usar consultas preparadas.

Forma 3: consultas preparadas

A idéia de se preparar uma consulta é dizer ao banco de dados o formato da consulta (apenas os parâmetros formais), e fazer a amarração dos parâmetros reais somente na hora da execução.
A maior parte dos bancos de dados suportam consultas preparadas, mas vou mostrar o exemplo usando MySQL, devido a popularidade.

<?php
$dbh = new mysqli("localhost", "ususario", "senha", "banco");
$c = $dbh->prepare("SELECT * FROM usuarios WHERE login = ? AND senha = ?");
$c->bind_param("login", $_POST['login']);
$c->bind_param("senha", $_POST['senha']);
$c->execute();
?>

Ou seja, primeiro informamos ao banco qual será a consulta a ser executada. Perceba que usamos interrogações no lugar dos parâmetros reais. Com isso, o banco prepara a consulta pra ser executada.
Logo em seguida, dizemos ao banco o valor que cada parâmetro irá receber. Esta etapa se chama amarração (binding). Como o banco de dados sabe o tipo de cada campo, ele também sabe como proceder pra escapar corretamente cada valor.
E por último, executamos a consulta. Simples, fácil e seguro!

Conclusão

SQL Injection é um problema sério que afeta muitos aplicativos web por aí afora, porém é um problema que só existe por causa da ingenuidade dos programadores, que não programam pensando em segurança. A solução, como vimos, é bem simples.

Artigos relacionados

• Criando CAPTCHAs em PHP
• Segurança no envio de emails em PHP
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Os 10 piores CAPTCHAs do mundo
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP

Como funciona na teoria?

O funcionamento de um CAPTCHA de letras tortas é bem simples. O servidor gera uma string que será transformada em uma imagem. A string é salva em algum lugar (normalmente em uma variável de sessão). A imagem é apresentada dentro de um formulário. Ao submeter o formulário, o script checa se o que o usuário digitou bate com o conteúdo da variável de sessão. Se bater, o usuário passou no teste.
Na teoria, tudo muito simples.

Mas e na prática?

Na prática, tudo também pode ser igualmente simples. Ao invés de reinventar a roda, podemos utilizar uma classe chamada Securimage, que serve justamente para gerar CAPTCHAs.

Securimage

Securimage é uma classe em PHP que utiliza a biblioteca gráfica GD para gerar imagens com CAPTCHAs. A classe é bastante versátil, e suporta várias opções, como fontes TTF, imagens de fundo, linhas, arcos e bem mais.
O primeiro passo é baixar o pacote com a versão mais recente e descompactá-lo em algum lugar. A partir deste ponto, vou assumir que o pacote foi descompactado em uma pasta chamada “securimage” no diretório raiz do site.

Criando o form com a imagem

Dentro do formulário que se deseja proteger, colocamos uma tag img, que irá conter a imagem gerada pelo Securimage:

<img id="captcha" src="/securimage/securimage_show.php" alt="CAPTCHA" />

Este script securimage_show.php é bem pequeno (3 linhas), e irá criar um CAPTCHA com as opções padrões da classe. Veremos mais adiante algumas formas de se customizar a imagem.
Além da imagem, também precisamos de um campo para o usuário digitar as letras contidas na imagem:

<input type="text" name="captcha_txt" />

E com isso o formulário está pronto.

A checagem no backend

O usuário viu a imagem, digitou os dados e submeteu o formulário. Agora é hora de checar se o código digitado bate com o texto contido na imagem.
Logo no início do script que recebe os dados do formulário (em caso de dúvida, veja o atributo action da tag form), é preciso inicializar as variáveis de sessão:

<?php session_start(); ?>

É importante que este código venha antes de qualquer saída, ou teremos um erro do tipo “Cannot modify header information – headers already sent….”. Na dúvida, coloque logo no início.
O restante da checagem é bastante simples. Basta instanciarmos um objeto da classe Securimage e chamar um método que faz a checagem:

<?php
require_once $_SERVER['DOCUMENT_ROOT'] . '/securimage/securimage.php';
$securimage = new Securimage();
 
if ($securimage->check($_POST['captcha_txt'])) {
    // Código digitado corretamente
    die("Ok, o código foi digitado corretamente.");
}
else {
    // Código digitado não bate com a imagem
    die("Erro: código incorreto.");
}
?>

O exemplo acima apenas ilustra como é feita a checagem. As chamadas a die() devem ser substituídas de acordo com a lógica da página onde o CAPTCHA está sendo inserido. No caso do código estar correto, deve-se prosseguir com o processamento do formulário, e caso não esteja, possivelmente exibir novamente o formulário com uma mensagem de erro. Será gerado um novo CAPTCHA automaticamente.

Outras opções

Como dito anteriormente, a classe é bastante versátil, e suporta diversas opções para a geração das imagens. Todas as opções estão descritas na documentação da classe, mas vou transcrever várias das opções aqui.
Para se customizar a imagem, basta editar diretamente o script securimage_show.php, que é o script usado na tag img. Originalmente, ele é apenas o seguinte:

<?php
include 'securimage.php';
$img = new securimage();
 
$img->show();
?>

Podemos passar opções para a classe antes de chamar o método show(). Apenas para ilustrar, aqui vai um exemplo bem customizado:

<?php
include 'securimage.php';
$img = new securimage();
$img->code_length = 8; // 8 ao invés de apenas 4 caracteres
$img->charset = "AEIOU"; // Apenas vogais
$img->image_width = 280; // Padrão é 175px para 4 caracteres
$img->multi_text_color = "#ff0000,#0000ff"; // Letras azuis e vermelhas
$img->image_bg_color = "#ffff00"; // Fundo amarelo
$img->show();
?>

E abaixo, 3 exemplos de CAPTCHAs gerados por este script:

Como já dito, a classe suporta muitas outras opções, o melhor mesmo é ler a documentação caso se deseje customizar mais.

Artigos relacionados

• Evitando SQL injection em PHP
• Os 10 piores CAPTCHAs do mundo
• Segurança no envio de emails em PHP
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP

A idéia de um CAPTCHA é mostrar graficamente um problema onde a solução é muito simples para um ser humano, mas muito difícil para um computador resolver. Normalmente, letras tortas servem bem para isso, pois é difícil para um programa conseguir diferenciar as letras.

Porém, existem casos em que os CAPTCHAs podem ser extremamente difíceis de se resolver, mesmo para seres humanos. Apenas pra descontrair um pouco, extraí os exemplos abaixo do blog do John Willis, e decidi compartilhar por achar interessantes. Escreverei em breve um artigo sobre a criação de CAPTCHAs, mas por enquanto, fiquemos apenas com os piores deles. Seguindo a mesma ordem do blog original, aqui vão eles, do melhor para o pior:

#10 – Fundo de plasma

Ok, este nem está tão ruim assim. Dá pra se ler claramente o que está escrito:

#9 – Letras parecidas

Alguem consegue olhar e me dizer de cara o que está escrito nessa imagem? Seria “muaummwwv”?

#8 – Substituição

A idéia desse é até interessante, mas convenhamos, não é nada prático. Um humano normalmente tolera perder uns 2 segundos no máximo com um CAPTCHA. Quanto tempo você perdeu pra chegar na resposta desse?

#7 – Impossível?

Este, sem a cola que tem logo embaixo, imagino que seja impossível. A imagem tá tão poluída que pelo menos eu não consegui distinguir nada ali.

#6 – Problema matemático

Ok, já vi alguns CAPTCHAs que pedem pra fazer contas simples de adição e subtração. Agora, um que pede pra resolver uma derivada ou encontrar raízes de polinômios de grau 5? Acreditem, é real! Verifiquem vocês mesmos. Caso não apareça a derivada de primeira, só dar reload até aparecer. Não demora muito.

O mais interessante é que esses problemas, embora assustem, são matematicamente muito simples de serem resolvidos. Esta derivada, fazendo x=0 acaba se tornando a derivada de uma constante, e todos nós coitados que já sofremos com estudamos cálculo I sabemos que a derivada de qualquer constante vale 0. Todas as derivadas que eu vi nesse site caem nessa categoria.

#5 – Psicodélico

Esse eu também não consegui distinguir nada. Qual será a resposta correta?

#4 – Texto na cor do fundo

Ok a imagem ter um fundo colorido com padrões pra dificultar a leitura automatizada da imagem, mas usar uma cor no texto quase igual a cor de fundo dificulta um pouco, não?

#3 – Que alfabeto é esse?

É uma sequencia grande de caracteres, só não sei de que língua ou alfabeto. Me parece que alguem na hora de bolar o CAPTCHA escolheu a fonte errada e acabaram saindo essas coisas estranhas:

#2 – Pontilhismo

Esse CAPTCHA deve ter sido feito por algum apreciador do impressionismo ou do pontilhismo. Alguém adivinha o que está escrito?

#1 – Not Found?

E quando a imagem não carrega? Como fazer pra resolver o CAPTCHA? Acho que de todos, este é o mais impossível de se resolver!

Alguém já esbarrou por aí em algum outro CAPTCHA que mereça entrar em uma galeria como esta?

Artigos relacionados

• Criando CAPTCHAs em PHP
• Evitando SQL injection em PHP
• Evitando spam em formulários
• Segurança no envio de emails em PHP

Até aí, tudo muito bonito. Funciona muito bem. Porém, os spammers acharam uma forma de propagar links para sites de origem duvidosa através destes formulários. Então, bolaram robôes que varrem a Internet em busca de formulários como estes. Ao encontrar um formulário, preenchem automaticamente todos os campos, e submetem os dados.

O resultado disso é o recebimento de várias mensagens inúteis com links muitas vezes utilizados pra disseminar vírus e outras ameaças.

Uma das formas de se resolver isso é colocando um CAPTCHA, aquelas imagens com letras tortas que teoricamente só um humano consegue decifrar. Alguns dos problemas com os CAPTCHAs: as vezes, o CAPTCHA é fraco, e é possível se usar um programa para quebrá-lo. Já aconteceu algumas vezes com serviços grandes, como Hotmail e Gmail. Outro problema, é que as vezes as letras ficam tão tortas que nem um humano consegue decifrar de primeira. Eu mesmo já tentei fazer um cadastro no BOL, e só consegui lá pra quarta ou quinta tentativa.

Uma outra forma, mais simples, consiste em se colocar no formulário um campo escondido via CSS. O formulário ficaria mais ou menos assim:

<form action="/email/send" method="post">
Nome: <input type="text" name="nome" /><br />
Email: <input type="text" name="email" /><br />
<input type="text" name="vazio" value="" style="display:none" />
<input type="submit" value="Enviar" />
</form>

Notem que o formulário possui um campo chamado vazio, que está escondido através do estilo “display:none“. A técnica é simples: o script que processa o post do formulário, verifica se este campo está preenchido ou não. Se estiver, muito provavelmente se trata de um robô fazendo spam, já que a princípio este campo não deveria nunca ser exibido na tela, e portanto não poderia ser preenchido.

Embora não seja 100% eficaz e peque um pouco pela falta de acessibilidade (já que dependendo do dispositivo que acesse o celular, o campo pode aparecer), ainda assim se trata de mais uma opção, ao meu ver, menos obstrusiva que um CAPTCHA.

NOTAS:

• O HTML acima está simples, sem seguir nenhum padrão, só para efeitos de demonstração da técnica. Deveria usar tags como <fieldset> e <label> para manter o formulário bonitinho;
• O style não deveria estar explícito no campo, e sim externo em um CSS, setando o display pra hidden ou através de uma classe ou através de um ID.

Já faço uso desta técnica em alguns sites que recebiam um volume considerável de spam automático, e hoje o nível caiu pra 0.

Outro aspecto do envio de email que também é extramamente importante é em relação ao spam envolvendo a manipulação dos cabeçalhos do email, como já descrito em um outro artigo.

Artigos relacionados

• Envio de emails em massa
• Evitando fornecer seu email verdadeiro
• Segurança no envio de emails em PHP
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Os 10 piores CAPTCHAs do mundo
• Envio de emails em PHP

Porém, se não forem tomados os devidos cuidados, sua aplicação pode ser explorada, e seu servidor pode passar a ser mais uma ferramente nas mãos dos spammers, pronto pra ficar enviando todo tipo de lixo pra meio mundo.

O principal problema com isso, além do fato do seu servidor passar a disseminar a praga que é o spam, é que seu servidor pode cair em algumas das listas negras, e com isso você passa a não conseguir mais enviar emails legítimos pra quem usa as tais listas pra se proteger contra o spam.

Resumindo: é uma dor de cabeça que você não quer ter.

Os cuidados que você precisa tomar no PHP pra não acabar com um problema desses é bem simples. Vamos ver, passo a passo, como normalmente é feito o envio de emails através do PHP, e onde podemos melhorá-lo.

Um formulário típico de contato de algum site, poderia ter a forma abaixo:

<form action="envia.php" method="post">
Nome: <input type="text" name="nome" /><br />
Email: <input type="text" name="email" /><br />
Mensagem: <textarea name="mensagem"></textarea><br />
<input type="submit" />
</form>

Ou seja, com o formulário acima, o usuário coloca seu nome, seu email, e a mensagem que deseja enviar. Ao se clicar no botão de submit, os dados são passados para o script envia.php, que tem a tarefa de enviar um email com a mensagem do usuário. Esse script, muitas vezes é implementado da seguinte forma, usando a função mail() do PHP:

<?php
$para = "equipe@site.com.br";
$assunto = "Contato do site";
$msg = $_POST['mensagem'];
$headers = "From: {$_POST['nome']} <{$_POST['email']}>";
mail($para, $assunto, $msg, $headers);
?>

Tudo muito bonito. O usuário envia seu nome, email e a mensagem, e o script PHP manda um email para equipe@site.com.br com o conteúdo do email. Estaria perfeito se não fosse pela montagem do cabeçalho From. O grande problema está em não tratar esses dados que foram enviados pelo usuário. Se o usuário faz o envio normalmente, teríamos um email mais ou menos assim (estou ignorando alguns cabeçalhos para simplificar o exemplo):

From: Bruno Lustosa <bruno@lustosa.net>
To: equipe@site.com.br
Subject: Contato do site
 
Olá, aqui vai a minha mensagem.

Nesse caso, postei meu nome, meu email, e a mensagem acima é enviada para a equipe do site. Porém, como o usuário tem o controle sobre o que entra no cabeçalho da mensagem, ele pode ser um pouco sacana, e colocar uma quebra de linha no nome dele, com algumas coisas depois. Por exemplo, se no lugar do meu nome eu coloco “Buy Viagra <xx@xx.com>nBcc: email1, email2, email3″ e na mensagem eu coloco algo sobre venda de viagra, teríamos o seguinte email montado:

From: Buy Viagra <xx@xx.com>
Bcc: email1, email2, email3
To: equipe@site.com.br
Subject: Contato do site
 
Compre Viagra, baratinho!!

Isso foi apenas um exemplo, mas dá pra combinar outras técnicas e conseguir por exemplo sobrescrever o assunto da mensagem. E hoje em dia, já existem robôs vasculhando formulários de sites buscando por vulnerabilidades desse tipo. Aconteceu em um código antigo da empresa onde estou trabalhando agora. Começamos a entrar em algumas listas negras e sem entender o porque. Quando fomos verificar a fila de emails esperando pra sair do servidor, eram mais de 30 mil spams sobre todo tipo de lixo. E vasculhando os logs do servidor web, chegamos ao script culpado.

É claro que isso NÃO É um problema do PHP. O PHP é tão seguro quanto uma pistola. Se o programador decide dar um tiro no próprio pé, não dá pra colocar a culpa na arma, não é? Esse é apenas mais um exemplo do tipo de problema que podemos enfrentar quando não validamos os dados enviados pelo usuário. Sempre que qualquer informação for enviada de um lugar não confiável, essa informação deve ser checada. Uma simples verificação em $_POST['nome'], buscando por quebras de linha, ou em $_POST['email'], verificando se se trata de um email válido, já resolveria esse problema.

A grande maioria dos problemas que vemos divulgados diariamente em todo tipo de script PHP se baseiam no fato de que os programadores não tem o hábito de programar pensando em segurança, e não fazem as checagens mais básicas, deixando os scripts vulneráveis a ataques como o descrito acima e outros.

Artigos relacionados

• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Evitando spam em formulários
• Envio de emails em PHP
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Envio de emails em massa
• Escrevendo plugins para o Wordpress
• Os 10 piores CAPTCHAs do mundo
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Validação de dados em PHP
• Evitando fornecer seu email verdadeiro