SQL Injection: PartiQL

A construção de uma instrução PartiQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos PartiQL arbitrários.

Injeção de SQL: Problemas de PartiQL 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 PartiQL.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta PartiQL que procura itens correspondentes a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais owner corresponde ao nome do usuário autenticado no momento.

...
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);
return displayResults(executeStatementResponse.Items);
...

A consulta pretende executar o seguinte código:

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

No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma string de consulta base constante e de uma string de entrada do usuário, ela apenas se comportará corretamente se itemName não contiver um caractere de aspas simples. Se um invasor com o nome de usuário wiley inserir a cadeia de caracteres "name' OR 'a'='a" para itemName, a consulta se tornará a seguinte:

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

A adição da condição OR 'a'='a' faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

Uma abordagem tradicional para evitar ataques de SQL injection é tratá-los como um problema de validação de entrada e, ou aceitar apenas caracteres de uma lista de permissão de valores seguros, ou identificar e escapar uma lista de valores possivelmente mal-intencionados. Verificar 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 negação é repleta de brechas que a tornam ineficaz na prevenção de ataques de SQL injection. Por exemplo, os invasores podem:

- Direcionar campos que não estão 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 PartiQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de injeção PartiQL.