SQL Injection

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

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 projetada para procurar faturas pertencentes a um usuário. A consulta restringe os itens exibidos àqueles nos quais o usuário corresponde ao nome do usuário autenticado no momento.

...
v_account = request->get_form_field( 'account' ).
v_reference = request->get_form_field( 'ref_key' ).

CONCATENATE `user = '` sy-uname `'` INTO cl_where.
IF v_account IS NOT INITIAL.
CONCATENATE cl_where ` AND account = ` v_account INTO cl_where SEPARATED BY SPACE.
ENDIF.
IF v_reference IS NOT INITIAL.
CONCATENATE cl_where "AND ref_key = `" v_reference "`" INTO cl_where.
ENDIF.

SELECT *
    FROM invoice_items
    INTO CORRESPONDING FIELDS OF TABLE itab_items
    WHERE (cl_where).
...

A consulta que esse código pretende executar é a seguinte (com a condição de que v_account e v_reference não sejam espaços em branco):

        SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = <account>
        AND ref_key = <reference>.

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 é uma candidata a ataques de SQL Injection. Se um invasor inserir a string "abc` OR MANDT NE `+" para v_reference e a string '1000' para v_account, a consulta se tornará a seguinte:

                SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
        WHERE user = sy-uname
        AND account = 1000
        AND ref_key = `abc` OR MANDT NE `+`.

A adição da condição OR MANDT NE `+` faz com que a cláusula WHERE sempre seja avaliada como "true", pois o campo "client" nunca pode ser igual ao literal +, e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

        SELECT * FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_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 invoice_items, independentemente do usuário especificado.

Exemplo 2: Neste exemplo, vamos considerar o uso da API ADBC em um programa que permite que os funcionários atualizem seus endereços.

        PARAMETERS: p_street TYPE string,
                    p_city TYPE string.

		Data: v_sql TYPE string,
			  stmt TYPE REF TO CL_SQL_STATEMENT.

v_sql = "UPDATE EMP_TABLE SET ".

"Update employee address. Build the update statement with changed details
IF street NE p_street.
CONCATENATE v_sql "STREET = `" p_street "`".
ENDIF.
IF city NE p_city.
CONCATENATE v_sql "CITY = `" p_city "`".
ENDIF.

l_upd      = stmt->execute_update( v_sql ).

Se um funcionário insatisfeito inserir uma string como "ABC` SALARY = `1000000" para o parâmetro p_street, o aplicativo permitirá que o banco de dados seja atualizado com o salário revisado!

Uma abordagem tradicional para evitar ataques de injeção de SQL é tratá-los como um problema de validação de entrada e aceitar apenas 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.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var username:String = String(params["username"]);
        var itemName:String = String(params["itemName"]);
        var query:String = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName;
          
        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.execute();
        ...

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

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

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 + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...

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

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

...
ctx.getAuthUserName(&userName); {
CString query = "SELECT * FROM items WHERE owner = '"
				 + userName + "' AND itemname = '"
				 + request.Lookup("item") + "'";
dbms.ExecuteSQL(query);
...

Exemplo 2:Como alternativa, um resultado semelhante pode ser obtido com o SQLite usando o seguinte código:

...
sprintf (sql, "SELECT * FROM items WHERE owner='%s' AND itemname='%s'", username, request.Lookup("item"));
printf("SQL to execute is: \n\t\t %s\n", sql);
rc = sqlite3_exec(db,sql, NULL,0, &err);
...

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 3: 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 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.

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

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 cria e executa dinamicamente uma consulta SQL projetada para pesquisar itens que correspondem a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais o proprietário é igual ao nome do usuário autenticado no momento.

...
ACCEPT USER.
ACCEPT ITM.
MOVE "SELECT * FROM items WHERE owner = '" TO QUERY1.
MOVE "' AND itemname = '" TO QUERY2.
MOVE "'" TO QUERY3.

STRING
  QUERY1, USER, QUERY2, ITM, QUERY3 DELIMITED BY SIZE
  INTO QUERY
END-STRING.
  
EXEC SQL
  EXECUTE IMMEDIATE :QUERY
END-EXEC.
...

A consulta que esse código pretende executar é a seguinte:

	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 itm, 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 seja sempre avaliada como verdadeira, 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: Neste exemplo, vamos considerar os efeitos de um valor mal-intencionado diferente passado para a consulta criada 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 essa cadeia de caracteres de ataque resultasse em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lotes de declarações separadas por ponto e vírgula, em bancos de dados com suporte esse tipo de ataque permitirá a execução de comandos arbitrários no banco de dados.

Observe o par de hífens (-) à direita; eles indicam 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 executado [4]. Nesse caso, os comentários são usados para remover o apóstrofo à direita que resta 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 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.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

...
<cfquery name="matchingItems" datasource="cfsnippets">
    SELECT * FROM items 
     WHERE owner='#Form.userName#'   
       AND itemId=#Form.ID#
</cfquery>
...

A consulta pretende executar o seguinte código:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemId = <ID>;

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 Form.ID 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 Form.ID, a consulta se tornará a seguinte:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemId = '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 hacker inserir a string "hacker'); DELETE FROM items; --" para Form.ID, a consulta se transformará nas duas consultas a seguir:

	SELECT * FROM items 
	WHERE owner = 'hacker'
	AND itemId = '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 = 'hacker'
	AND itemId = '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 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.

Usar o Java J2EE PersistenceAPI para executar uma instrução SQL dinâmica construída com entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.

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 o proprietário corresponde ao nome do usuário autenticado no momento.

...
	final server = await HttpServer.bind('localhost', 18081);
    server.listen((request) async {
        final headers = request.headers;
        final userName = headers.value('userName');
        final itemName = headers.value('itemName');
        final query = "SELECT * FROM items WHERE owner = '"
            + userName! + "' AND itemname = '"
            + itemName! + "'";
        db.query(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 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:

	SELECT * FROM items;

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta só deve retornar itens pertencentes ao 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 cadeia de caracteres "name'; DELETE FROM items; --" para itemName, a consulta se transformará nas duas seguintes consultas:

	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 essa cadeia de caracteres de 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 no 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 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 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, 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.

A criação de uma instrução SQL dinâmica com entrada proveniente de uma fonte não confiável permite que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.

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 o proprietário corresponde ao nome do usuário autenticado no momento.

  ...
  rawQuery := request.URL.Query()
  username := rawQuery.Get("userName")
  itemName := rawQuery.Get("itemName")
  query := "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";"

  db.Exec(query)
  ...

A consulta pretende executar o seguinte código:

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

No entanto, como o código cria dinamicamente a consulta concatenando uma cadeia de caracteres de consulta base constante e uma cadeia de caracteres de entrada do usuário, a consulta só 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:

	SELECT * FROM items;

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta só deve retornar itens pertencentes ao 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 cadeia de caracteres "name'; DELETE FROM items; --" para itemName, a consulta se transformará nas duas seguintes consultas:

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

	DELETE FROM items;

	--'

Muitos servidores de banco de dados, inclusive o Microsoft SQL Server 2000, permitem a execução simultânea de várias instruções SQL separadas por ponto e vírgula. Embora essa cadeia de caracteres de 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 no 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 cadeia de caracteres "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", as três seguintes instruções válidas 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 impedir 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 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 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 bloqueios é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL. 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 de consultas SQL pode ajudar, mas não protege seu aplicativo 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, 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. Novamente, os procedimentos armazenados podem impedir algumas explorações, mas não protegem seu aplicativo contra ataques de SQL injection.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

	...
	var username = document.form.username.value;
	var itemName = document.form.itemName.value;
	var query = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";";
	db.transaction(function (tx) {
		tx.executeSql(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 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.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

	...
	$userName = $_SESSION['userName'];
	$itemName = $_POST['itemName'];
	$query = "SELECT * FROM items WHERE owner = '$userName' AND itemname = '$itemName';";
	$result = mysql_query($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 concatenando uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada do usuário, a consulta só se comportará corretamente se itemName não tiver 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 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.

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

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 cria e executa dinamicamente uma consulta SQL projetada para pesquisar itens que correspondem a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais o proprietário é igual ao nome do usuário autenticado no momento.

procedure get_item (
     itm_cv IN OUT ItmCurTyp,
     usr in varchar2,
     itm in varchar2)
is
     open itm_cv for ' SELECT * FROM items WHERE ' ||
                   'owner = '''|| usr || '''' ||
                   ' AND itemname = ''' || itm || '''';
     end get_item;

A consulta que esse código pretende executar é a seguinte:

	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 itm, 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 seja sempre avaliada como verdadeira, 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: Neste exemplo, vamos considerar os efeitos de um valor mal-intencionado diferente passado para a consulta criada 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 essa cadeia de caracteres de ataque resultasse em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lotes de declarações separadas por ponto e vírgula, em bancos de dados com suporte esse tipo de ataque permitirá a execução de comandos arbitrários no banco de dados.

Observe o par de hífens (-) à direita; eles indicam 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 executado [4]. Nesse caso, os comentários são usados para remover o apóstrofo à direita que resta 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 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. Como essa série de exemplos mostrou, os procedimentos armazenados podem ser tão vulneráveis quanto outros tipos de código. Os procedimentos armazenados podem ajudar a prevenir certos tipos de ataques, mas eles não vão fazer com que seu aplicativo esteja intrinsecamente seguro contra ataques de SQL Injection.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

	...
	userName = req.field('userName')
	itemName = req.field('itemName')
	query = "SELECT * FROM items WHERE owner = ' " + userName +" ' AND itemname = ' " + itemName +"';"
	cursor.execute(query)
	result = cursor.fetchall()
	...

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 concatenando uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada do usuário, a consulta só se comportará corretamente se itemName não tiver 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 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.

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

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.

...
  userName = getAuthenticatedUserName()
  itemName = params[:itemName]
  sqlQuery = "SELECT * FROM items WHERE owner = '#{userName}' AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

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.

Devido ao fato de que a Ruby não é digitada estaticamente também permite outros pontos de injeção em consultas SQL, que podem não estar disponíveis em linguagens de digitação estática.
Exemplo 2: 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.

...
  id = params[:id]
  itemName = Mysql.escape_string(params[:itemName])
  sqlQuery = "SELECT * FROM items WHERE id = #{userName} AND itemname = '#{itemName}'"
  rs = conn.query(sqlQuery)
...

Nesse caso, a consulta SQL esperada a ser executada é:

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

Dessa vez você pode ver que nos protegemos contra um invasor ao especificar uma única citação dentro deitemName e aparentemente isso impediu a vulnerabilidade contra a SQL Injection. No entanto, como a Ruby não é uma linguagem de digitação estática, mesmo que nós esperemos que id seja um número inteiro de algum tipo uma vez que ele é atribuído a partir da entrada do usuário, ele não será necessariamente um número. Se um invasor puder, em vez disso, alterar o valor de id para 1 OR id!=1--, uma vez que não há nenhuma verificação de que id é de fato numérico, a consulta SQL agora se tornará:

SELECT * FROM items WHERE id=1 OR id!=1-- AND itemname = 'anyValue';

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]. Portanto, isso executará apenas uma consulta SQL que consiste em:

SELECT * FROM items WHERE id=1 OR id!=1;

Agora estamos apenas selecionando tudo naquela tabela, mesmo se o valor de id for igual a 1 ou não, o que naturalmente, equivale a tudo nessa tabela.

Muitos servidores de banco de dados permitem que várias instruções SQL separadas por ponto e vírgula sejam executadas ao mesmo tempo. 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.

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.

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

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 usuários correspondentes a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais o proprietário corresponde ao nome do usuário fornecido como um parâmetro de caminho.

  def doSQLQuery(value:String) = Action.async { implicit request =>
    val result: Future[Seq[User]] = db.run {
      sql"select * from users where name = '#$value'".as[User]
    }
    ...
  }

A consulta pretende executar o seguinte código:

	SELECT * FROM users 
	WHERE name = <userName>

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 userName 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 userName, a consulta se tornará a seguinte:

	SELECT * FROM users 
    WHERE name = '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 users;

Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deva retornar apenas os usuários pertencentes ao usuário especificado. Agora ela retorna todas as entradas armazenadas na tabela users, independentemente do usuário especificado.

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.

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

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.

...
let queryStatementString = "SELECT * FROM items WHERE owner='\(username)' AND itemname='\(item)'"
var queryStatement: OpaquePointer? = nil
if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
    if sqlite3_step(queryStatement) == SQLITE_ROW {
    ...
    }
}
...

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

- Voltar-se para 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 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 injeção de SQL.

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

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 o proprietário corresponde ao nome do usuário autenticado no momento.

	...
	username = Session("username")
	itemName = Request.Form("itemName")
	strSQL = "SELECT * FROM items WHERE owner = '"& userName &"' AND itemname = '" & itemName &"'"
	objRecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
	...

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