SQL Injection: PartiQL

La creación de una instrucción PartiQL dinámica con información procedente de un origen que no es de confianza podría permitir que un atacante malintencionado modificara el significado de la instrucción o ejecutara comandos PartiQL arbitrarios.

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.User;
string itemName = apiGatewayProxyRequest.QueryStringParameters['item'];
string statement = $"SELECT * FROM items WHERE owner = '{userName}' AND itemname = '{itemName}'";

var executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.Statement = statement;
var executeStatementResponse = await dynamoDBClient.ExecuteStatementAsync(executeStatementRequest);
devolver displayResults(executeStatementResponse.Items);
...

La consulta intenta ejecutar el código siguiente:

	Elementos SELECT * FROM
	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:

	Elementos SELECT * FROM
	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.