SQL Injection: Poor Validation

Contar com HTML, XML ou outros tipos de codificação para validar a entrada não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.

O uso de funções de codificação, como mysql_real_escape_string(), impedirá algumas vulnerabilidades de injeção de SQL, mas nem todas. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a injeção de SQL, podendo permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários. Como nem sempre é possível determinar de forma estática onde a entrada será exibida dentro de uma determinada seção de código interpretado dinamicamente, os rulepacks do Fortify Secure Coding podem apresentar dados SQL dinâmicos validados como problemas de “SQL Injection: Validação Insuficiente", mesmo que a validação possa ser suficiente para evitar a SQL Injection nesse contexto.

Erros de SQL injection ocorrem quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta SQL.

Exemplo 1: O exemplo a seguir demonstra como a configuração do banco de dados pode alterar o comportamento de mysqli_real_escape_string(). Quando o modo SQL está definido como "NO_BACKSLASH_ESCAPES", o caractere de barra invertida é tratado como um caractere normal, não como um caractere de escape[5]. Como mysqli_real_escape_string() leva isso em consideração, a consulta a seguir é vulnerável à SQL injection, pois " não tem mais o escape para \" devido à configuração do banco de dados.

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

Se o invasor deixar o campo password em branco e inserir " OR 1=1;-- para userName, as aspas não terão escape, e a consulta resultante será a seguinte:

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

Como OR 1=1 faz com que a cláusula where sempre seja avaliada como true e os hifens duplos fazem com que o resto da instrução seja tratado como um comentário, a consulta se torna equivalente à lógica de uma consulta muito mais simples:

  SELECT * FROM users;

Uma abordagem tradicional para evitar ataques de injeção de SQL é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões de valores seguros, ou identificar e fazer o escape em uma lista de valores potencialmente mal-intencionados (lista de bloqueios). O confronto com uma lista de permissões pode ser um meio muito eficaz de impor regras de validação de entrada rigorosas, mas instruções SQL parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a implementação de uma lista de permissões é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL. Por exemplo, os invasores podem:

- Intencionar campos que não estejam entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas SQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL injection.

Outra solução comumente proposta para lidar com ataques de SQL injection é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de SQL injection, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL injection limitando os tipos de instruções que podem ser transmitidos a seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas instruções interessantes que ainda podem ser transmitidas para procedimentos armazenados. Mais uma vez, os procedimentos armazenados podem impedir algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL injection.