Não "higienize" input como meio de evitar SQL Injection - usar marcadores (ou escape adequado) , sempre. Ser consistente. Ser seguro. O problema já está resolvido.

Este caso será "seguro" devido ao domínio limitado do base64_encode função. No entanto..

É é má prática e armazenar valores codificados em base64 (de modo que a consulta mostrada possa funcionar) carrega vários negativos implicações à medida que muda a informação armazenada:ela destrói a ordenação de valores, torna a informação não pesquisável trivialmente , requer um adicional etapa "codificar/decodificar" e até consome mais espaço - ai!

Assim, embora possa haver casos específicos para dados de codificação base64, essa abordagem não adequado como meio de mitigar SQL Injection .

O problema é devido ao acesso ao SQL através de um protocolo de texto onde o comando/forma da consulta e os valores são misturados. O uso de correto técnicas de escape (por exemplo, mysql_real_escape_string ) corrige isso garantindo que as informações sejam escapadas para que o texto SQL seja analisado como pretendido - no entanto, ao contrário de uma etapa de codificação base64, ela não realmente alterar as informações fornecidas!

Este é exatamente o que os marcadores fornecem ! Os espaços reservados são os abordagem universalmente correta e deve ser incentivada. Espaços reservados permitem que a consulta e os valores sejam enviados ao banco de dados separadamente quando suportado pela biblioteca/banco de dados; e são emulados escapando de outra forma. O uso correto do espaço reservado elimina SQL Injection e a necessidade de código do usuário para misturar valores no texto do comando SQL, o que também pode tornar as consultas mais fáceis de escrever e manter.

Para evitar que "programadores individuais" escrevam consultas terríveis, a solução é prevenir consultas ad-hoc sejam espalhadas no código:colete as operações de acesso a dados em uma Data Access Layer ( DAL) (possivelmente em conjunto com um ORM) e apenas expor ações relevantes, garantindo o uso adequado do SQL dentro do DAL. Em projetos mais simples, o DAL também é um local adequado para gerenciar centralmente as regras de negócios para saneamento e outras lógicas de validação.

Mais precisamente:

• 
  Higienizar valores para regras de negócios; isso deve evitar "informações incorretas", como um nome de usuário muito curto, que contém caracteres restritos ou que não atende aos requisitos comerciais.
  
• 
  Usar marcadores para evitar SQL Injection . Isso é estritamente relacionado à transferência de dados para SQL e não tem relação com as informações nele contidas.
  

Enquanto o MySQL 5.6.1 adiciona FROM_BASE64 , de modo que a codificação possa simplesmente ser usada no texto do comando SQL, isso ainda adiciona uma etapa de decodificação explícita adicional e complica a consulta ao usar esse esquema de codificação. Essa abordagem base64 simplesmente não necessário, pois já existem técnicas comprovadas para evitar injeção de SQL, e não foi proposto na pergunta inicial.