Proteção de injeção de SQL

Isso não do que se trata a injeção de SQL. Sempre que você usa parâmetros que não foram higienizados em sua consulta SQL, você deixa seu banco de dados aberto para injeção de SQL, que pode não necessariamente ter o objetivo de destruir dados. Também pode ser para roubar dados ou obter acesso não autorizado.

Considere uma conta muito restrita onde tudo o que poderia fazer é SELECT . Você escreve uma consulta para autenticação:

$sql = "SELECT COUNT(*) AS count
          FROM users 
         WHERE user_id='{$_POST['user']}' AND pass='{$_POST['password'}'";

// check if returns a count of 1, if yes, log in

Com a entrada normal, você espera que a consulta seja semelhante a:

SELECT COUNT(*) AS count
  FROM users 
 WHERE user_id = 'username' AND pass='********'

Que deve retornar 1 como a contagem se o nome de usuário e a senha corresponderem. Agora, um invasor tenta fazer login como administrador. Como você não limpou suas entradas, elas enviam $_POST['user'] como:admin'; -- . A consulta inteira se torna:

SELECT COUNT(*) AS count
  FROM users 
 WHERE user_id = 'admin'; -- AND pass='********'

Tudo depois de -- é um comentário, então isso ignora a outra condição e retorna 1 independentemente. Pronto, você acabou de conceder acesso de administrador a um usuário malicioso. É assim que alguns ataques reais são realizados. Você começa com uma conta com poucos privilégios e, através de falhas na segurança, tenta obter acesso a mais privilégios.

Para encurtar a história, ter uma conta em todo o aplicativo com privilégios restritos (por exemplo:sem DROP , ALTER , etc) é bom. Nunca dê a ninguém ou a qualquer aplicativo mais privilégios do que eles precisam. Mas para evitar injeção de SQL, use instruções preparadas .