SQL Injection: Poor Validation

El uso de HTML, XML y otros tipos de codificación para validar entradas que no son de confianza puede permitir que un atacante modifique el significado de la instrucción o que ejecute comandos SQL arbitrarios.

El uso de funciones de codificación como mysql_real_escape_string() evitará algunas de las vulnerabilidades SQL Injection, pero no todas. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar vulnerabilidades SQL Injection y puede permitir que un atacante modifique el significado de la instrucción o que ejecute comandos SQL arbitrarios. Dado que no siempre es posible determinar estáticamente dónde aparecerá la entrada en una sección determinada de código de interpretación dinámica, Fortify Secure Coding Rulepacks puede presentar datos SQL dinámicos validados como problemas "SQL Injection: Poor Validation", aunque la validación pueda ser suficiente para evitar los problemas SQL Injection en ese contexto.

Los errores SQL Injection se producen cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: El siguiente ejemplo demuestra el modo en que la configuración de la base de datos puede modificar el comportamiento de mysqli_real_escape_string(). Cuando el modo SQL está establecido como "NO_BACKSLASH_ESCAPES", el carácter de barra diagonal inversa se trata como un carácter normal y no como un carácter de escape[5]. Dado que mysqli_real_escape_string() tiene en cuenta esta configuración, la siguiente consulta es vulnerable a SQL Injection porque, conforme a la configuración de la base de datos, ya no se produce un escape de " a \".

  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);
  ...

Si un atacante deja en blanco el campo password e introduce " OR 1=1;-- para userName, no se aplicará el escape a las comillas y la consulta resultante será la siguiente:

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

Dado que OR 1=1 hace que la cláusula where siempre se evalúe como true y los guiones dobles hacen que el resto de la instrucción se trate como un comentario, la consulta pasará a ser equivalente lógicamente a la siguiente consulta más simple:

  SELECT * FROM users;

Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas.
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

La asignación manual de escapes a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos ataques, pero no garantizarán la protección de la aplicación frente a ataques SQL Injection.