Se producen errores de SQL Injection 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 código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos en los que owner coincide con el nombre de usuario del usuario actualmente autenticado.

...
	string userName = ctx.GetAuthenticatedUserName();
	string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

La consulta intenta ejecutar el código siguiente:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si ItemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para ItemName, la consulta se convertirá en lo siguiente:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

	SELECT * FROM items;

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para ItemName, la consulta se convertirá en las dos consultas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

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 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

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

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

Inyección de código SQL: Los problemas de PartiQL ocurren cuando:

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

2. Los datos se utilizan para crear dinámicamente una consulta PartiQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta PartiQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde owner coincide con el nombre de usuario del usuario autenticado actualmente.

...
String userName = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...

La consulta intenta ejecutar el código siguiente:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:
Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques 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 caracteres de escape en la entrada de las consultas PartiQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques de inyección PartiQL.

Se producen errores de SQL Injection cuando:

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

En este caso, Fortify Static Code Analyzer no pudo determinar si el origen de los datos era de confianza.

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

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

La consulta intenta ejecutar el código siguiente:

        SELECT * FROM items
        WHERE owner = <userName>
        AND itemname = <itemName>;

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name' OR 'a'='a';

La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

        SELECT * FROM items;

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        --'

Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general podría seguir siendo eficaz mediante un truco similar al que se utilizó en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        SELECT * FROM items WHERE 'a'='a';

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la SQL Injection no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 3: el siguiente código adapta el Example 1 a la plataforma Android.

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

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

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

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

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.

Los errores de SQL Injection relacionados con SubSonic 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 de forma dinámica una consulta.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SubSonic de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos en los que owner coincide con el nombre de usuario del usuario actualmente autenticado.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

La consulta intenta ejecutar el código siguiente:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

	SELECT * FROM items;

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'); DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

Un enfoque tradicional para la prevención de ataques de inyección de SubSonic 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 SubSonic 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 inyección de SubSonic. 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

Al establecer manualmente escapes en los caracteres de la entrada de las consultas de SubSonic puede resultar útil, pero esto no logrará que la aplicación sea invulnerable a los ataques de SQL Injection de SubSonic.

Otra solución propuesta habitualmente para abordar los ataques de inyección de SubSonic consiste en utilizar procedimientos almacenados. Aunque los procedimientos almacenados impiden que se produzcan algunos tipos de ataques de inyección de SubSonic, estos no son capaces de ofrecer protección frente a muchos otros. Por lo general, los procedimientos almacenados ayudan a prevenir los ataques de SQL Injection de SubSonic mediante la limitación de los tipos de instrucciones que se pueden transferir a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos pueden impedir algunos ataques, pero no lograrán proteger la aplicación frente a ataques de inyección de SubSonic.