Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

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