Se você usar a entrada do usuário e inserir sem modificar uma consulta SQL, o aplicativo se tornará vulnerável a injeção e SQL, como no exemplo a seguir:

$unsafe_variable = $_POST['user_input']; 
mysql_query("INSERT INTO `table` (`column`) VALUES ('$unsafe_variable')");

Isso ocorre porque o usuário pode inserir algo como value'); DROP TABLE table;--, e a consulta se torna:

INSERT INTO `table` (`column`) VALUES('value'); DROP TABLE table;--')

Como Evitar que isso Aconteça?

A maneira correta de evitar ataques de injeção de SQL, não importa qual banco de dados você use, é separar os dados do SQL , de modo que os dados permaneçam dados e nunca sejam interpretados como comandos pelo analisador SQL. É possível criar uma instrução SQL com partes de dados formatadas corretamente, mas se você não entender completamente os detalhes, você deve sempre usar instruções preparadas e consultas parametrizadas. Essas são instruções SQL enviadas e analisadas pelo servidor de banco de dados separadamente de quaisquer parâmetros. Dessa forma, é impossível para um invasor injetar SQL malicioso.

Você tem basicamente duas opções para conseguir isso:

  1. Usando PDO (para qualquer driver de banco de dados compatível):$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute([ 'name' => $name ]); foreach ($stmt as $row) { // Do something with $row }
  2. Usando MySQLi (para MySQL):$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?'); $stmt->bind_param('s', $name); // 's' specifies the variable type => 'string' $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) { // Do something with $row }

Se você estiver se conectando a um banco de dados diferente do MySQL, há uma segunda opção específica do driver que você pode consultar (por exemplo, pg_prepare()pg_execute() para PostgreSQL). O PDO é a opção universal.


Configurando corretamente a conexão

Observe que, ao usar PDO para acessar um banco de dados MySQL, instruções reais preparadas não são usadas por padrão . Para corrigir isso, você deve desativar a emulação de instruções preparadas. Um exemplo de criação de uma conexão usando PDO é:

$dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'password');
$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

No exemplo acima, o modo de erro não é estritamente necessário, mas é aconselhável adicioná-lo . Dessa forma, o script não irá parar Fatal Error quando algo der errado. E dá ao desenvolvedor a chance de catch qualquer erro(s) que são throw como PDOException.

O que é obrigatório , no entanto, é a primeira setAttribute() linha, que diz ao PDO para desabilitar as instruções preparadas emuladas e usar as instruções preparadas reais . Isso garante que a instrução e os valores não sejam analisados ​​pelo PHP antes de enviá-los ao servidor MySQL (não dando a um possível invasor nenhuma chance de injetar SQL malicioso).

Embora você possa definir o charset nas opções do construtor, é importante notar que as versões ‘mais antigas’ do PHP (antes de 5.3.6) ignoraram silenciosamente o parâmetro charset no DSN.


Explicação

A instrução SQL que você passa prepare é analisada e compilada pelo servidor de banco de dados. Ao especificar parâmetros (um ? ou um parâmetro nomeado como :name no exemplo acima), você informa ao mecanismo de banco de dados onde deseja filtrar. Então, quando você chama execute, a instrução preparada é combinada com os valores de parâmetro que você especificar.

O importante aqui é que os valores dos parâmetros sejam combinados com a instrução compilada, não com uma string SQL. A injeção de SQL funciona enganando o script, fazendo-o incluir strings maliciosas ao criar SQL para enviar ao banco de dados. Portanto, ao enviar o SQL real separadamente dos parâmetros, você limita o risco de terminar com algo que não pretendia.

Quaisquer parâmetros que você enviar ao usar uma instrução preparada serão tratados apenas como strings (embora o mecanismo de banco de dados possa fazer alguma otimização, então os parâmetros podem acabar como números também, é claro). No exemplo acima, se a $namevariável contiver 'Sarah'; DELETE FROM employeeso resultado seria simplesmente uma busca pela string "'Sarah'; DELETE FROM employees", e você não terminará com uma tabela vazia .

Outro benefício de usar instruções preparadas é que, se você executar a mesma instrução muitas vezes na mesma sessão, ela será analisada e compilada apenas uma vez, proporcionando alguns ganhos de velocidade.

Ah, e já que você perguntou como fazer isso para uma inserção, aqui está um exemplo (usando PDO):

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute([ 'column' => $unsafeValue ]);

As declarações preparadas podem ser usadas para consultas dinâmicas?

Embora você ainda possa usar instruções preparadas para os parâmetros de consulta, a estrutura da própria consulta dinâmica não pode ser parametrizada e certos recursos de consulta não podem ser parametrizados.

Para esses cenários específicos, a melhor coisa a fazer é usar um filtro de lista de desbloqueio que restrinja os valores possíveis.

// Lista de permissões de valor
// $dir só pode ser 'DESC', caso contrário, será 'ASC'
if (empty($dir) || $dir !== 'DESC') {
   $dir = 'ASC';
}