Depois de ter escrito sobre o ataque em http://dascoisasqueaprendi.com.br/tiseguranca/sql-injection-outro-foco/, vou falar sobre algumas maneiras de se prevenir. Apesar do foco ser aplicações em PHP, as dicas servem para outras linguagens. Aliás, é sempre bom ter em mente que, por se tratar de um ataque direcionado à linguagem SQL, toda aplicação que a utilize para consultas no banco de dados deve ser protegida. Cientes disso, seguem as dicas:

Habilitar "magic quotes" no PHP: apesar de ser uma ótima ação na prevenção contra SQL Injection, pode ter efeitos colaterais desagradáveis. Habilitar essa propriedade no PHP torna sua aplicação mais lenta. Além disso, já é uma função considerada obsoleta na versão 5.3 do PHP e deve ser descontinuada nas próximas versões. Portanto, não seria aconselhável confiar sua proteção em algo que não durará muito tempo.

Usar a função addslashes(): essa função tem o mesmo efeito que habilitar magic_quotes com a vantagem de ser aplicada apenas onde for conveniente. Na prática, ela põe o caracter de escape antes de aspas simples ou duplas, antes da barra invertida e antes do cacater NULL. Lembrando que, para retornar ao texto original, é necessário usar a função stripslashes().

Fazer uma validação na entrada: é extremamente importante que, antes de qualquer outra manipulação nos dados, seja feita uma validação para certificar que estão num padrão aceitável. Por exemplo, verificar se campos numéricos têm apenas números, se as datas estão num formato adequado, se o login do usuário tem apenas letras e números etc.

Usar prepared statements ao invés do código SQL diretamente: as duas dicas acima já são extremamente eficazes na prevenção de SQL Injection. Entretanto, além de uma proteção adicional, usar prepared statements pode também lhe trazer um incremento na performance de suas consultas ao banco de dados.

Limitar os privilégios das contas com acesso ao banco de dados: é muito importante, em qualquer aplicação, que as contas de acesso ao banco de dados tenham apenas os privilégios necessários à execução de suas funções. Muitas vezes, somos tentados a definir o nível de acesso da conta usando comandos como:
para não termos "problemas de acesso". Na verdade, acabamos tendo problemas bem maiores porque criamos um super usuário com poderes suficientes para nos causar muitos danos. Entre outros, o privilégio FILE, que permite o ataque citado no post anterior.