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 código a seguir constrói e executa dinamicamente uma consulta SQL 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 = ctx.GetAuthenticatedUserName();
	string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

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 string "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:

	SELECT * FROM items;

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todas as entradas armazenadas na tabela items, independentemente do proprietário especificado.

Exemplo 2: Esse exemplo examina os efeitos de um valor mal-intencionado diferente transmitido para a consulta construída e executada no Example 1. Se um invasor com o nome de usuário wiley inserir a string "name'; DELETE FROM items; --" para ItemName, a consulta se transformará nas duas consultas a seguir:

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

	DELETE FROM items;

	--'

Muitos servidores de banco de dados, incluindo o Microsoft SQL Server 2000, permitem que várias instruções SQL separadas por ponto-e-vírgula sejam executadas de uma vez. Embora esse ataque resulte em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lote de instruções separadas por ponto-e-vírgula, em bancos de dados que permitem a execução em lote, esse tipo de ataque permite que o invasor execute comandos arbitrários direcionados ao banco de dados.

Observe o par de hifens (--) à direita, que especifica para a maioria dos servidores de banco de dados que o restante da instrução deve ser tratado como um comentário e não deve ser executado [4]. Nesse caso, o caractere de comentário serve para remover as aspas simples à direita que sobraram da consulta modificada. Em um banco de dados no qual comentários não podem ser utilizados dessa maneira, o ataque geral ainda pode se tornar efetivo com o uso de um truque semelhante ao mostrado no Example 1. Se um invasor inserir a string "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", as três instruções válidas a seguir serão criadas:

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

	DELETE FROM items;

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

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 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 alguns tipos de explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL Injection.

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

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.

Erros de SQL Injection ocorrem quando:

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

Nesse caso, o Fortify Static Code Analyzer não conseguiu determinar se a fonte dos dados é confiável.

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

Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta SQL que procura itens correspondentes a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais o proprietário corresponde ao nome do usuário autenticado no momento.

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

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 string "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:

        SELECT * FROM items;

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todas as entradas armazenadas na tabela items, independentemente do proprietário especificado.

Exemplo 2: Esse exemplo examina os efeitos de um valor mal-intencionado diferente transmitido para a consulta construída e executada no Example 1. Se um invasor com o nome de usuário wiley inserir a string "name'; DELETE FROM items; --" para itemName, a consulta se transformará nas duas consultas a seguir:

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

        DELETE FROM items;

        --'

Muitos servidores de banco de dados, incluindo o Microsoft SQL Server 2000, permitem que várias instruções SQL separadas por ponto-e-vírgula sejam executadas de uma vez. Embora esse ataque resulte em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lote de instruções separadas por ponto-e-vírgula, em bancos de dados que permitem a execução em lote, esse tipo de ataque permite que o invasor execute comandos arbitrários direcionados ao banco de dados.

Observe o par de hifens (--) à direita, que especifica para a maioria dos servidores de banco de dados que o restante da instrução deve ser tratado como um comentário e não deve ser executado [4]. Nesse caso, o caractere de comentário serve para remover as aspas simples à direita que sobraram da consulta modificada. Em um banco de dados no qual comentários não podem ser utilizados dessa maneira, o ataque geral ainda pode se tornar efetivo com o uso de um truque semelhante ao usado no Example 1. Se um invasor inserir a string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", as três instruções válidas a seguir serão criadas:

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

        DELETE FROM items;

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

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como a SQL Injection, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir adapta o Example 1 à 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);
...

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.

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.

Erros de SQL Injection relacionados ao SubSonic 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.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta SubSonic 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 = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

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

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 string "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:

	SELECT * FROM items;

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todas as entradas armazenadas na tabela items, independentemente do proprietário especificado.

Exemplo 2: Esse exemplo examina os efeitos de um valor mal-intencionado diferente transmitido para a consulta construída e executada no Example 1. Se um invasor com o nome de usuário wiley inserir a string "name'); DELETE FROM items; --" para itemName, a consulta se transformará nas duas consultas a seguir:

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

	DELETE FROM items;

	--'

Muitos servidores de banco de dados, incluindo o Microsoft SQL Server 2000, permitem que várias instruções SQL separadas por ponto-e-vírgula sejam executadas de uma vez. Embora esse ataque resulte em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lote de instruções separadas por ponto-e-vírgula, em bancos de dados que permitem a execução em lote, esse tipo de ataque permite que o invasor execute comandos arbitrários direcionados ao banco de dados.

Observe o par de hifens (--) à direita, que especifica para a maioria dos servidores de banco de dados que o restante da instrução deve ser tratado como um comentário e não deve ser executado [4]. Nesse caso, o caractere de comentário serve para remover as aspas simples à direita que sobraram da consulta modificada. Em um banco de dados no qual comentários não podem ser utilizados dessa maneira, o ataque geral ainda pode se tornar efetivo com o uso de um truque semelhante ao mostrado no Example 1. Se um invasor inserir a string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", as três instruções válidas a seguir serão criadas:

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

	DELETE FROM items;

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

Uma abordagem tradicional para evitar ataques de injeção de SubSonic é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões com 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 SubSonic parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a aplicação de uma lista de bloqueios é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL SubSonic. 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 SubSonic pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL Injection SubSonic.

Outra solução comumente proposta para lidar com ataques de injeção de SubSonic é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de injeção de SubSonic, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL Injection SubSonic 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 injeção de SubSonic.