Reino: Input Validation and Representation

Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.

12 itens encontrados
Vulnerabilidades
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.

References
[1] SAP OSS notes 1520356, 1487337, 1502272 and related notes.
[2] S. J. Friedl SQL Injection Attacks by Example
[3] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[4] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[5] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.abap.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.actionscript.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.dotnet.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Parameterized CRecordset and CDatabase for SQL Server
[6] Parameterizing a Recordset Microsoft
[7] ODBC API Reference: SQLNumParams() Microsoft
[8] ODBC API Reference: SQLBindParameter() Microsoft
[9] OLE DB Reference: ICommandWithParameters Microsoft
desc.dataflow.cpp.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.cobol.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.cfml.sql_injection
Abstract
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.
Explanation
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.
desc.dataflow.dart.sql_injection
Abstract
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.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.golang.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.


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


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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
desc.dataflow.java.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.javascript.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.php.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] David Litchfield Lateral SQL Injection: A New Class of Vulnerability in Oracle
desc.dataflow.sql.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.python.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.ruby.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
desc.dataflow.scala.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Parameterized CRecordset and CDatabase for SQL Server
[6] Parameterizing a Recordset Microsoft
[7] ODBC API Reference: SQLNumParams() Microsoft
[8] ODBC API Reference: SQLBindParameter() Microsoft
[9] OLE DB Reference: ICommandWithParameters Microsoft
desc.dataflow.swift.sql_injection
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.vb.sql_injection
Abstract
A construção de uma instrução Castle ActiveRecord dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
Erros de SQL Injection relacionados ao Castle ActiveRecord 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 Castle ActiveRecord 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 queryString = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ ItemName.Text + "'";

SimpleQuery<Item> queryObject = new SimpleQuery(queryString);
Item[] items = (Item[])queryObject.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.

Uma abordagem tradicional para evitar ataques de injeção de Castle ActiveRecord é 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 com 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 Castle ActiveRecord 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 Castle ActiveRecord. 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 Castle ActiveRecord pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL Injection Castle ActiveRecord.

Outra solução comumente proposta para lidar com ataques de injeção de Castle ActiveRecord é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de injeção de Castle ActiveRecord, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL Injection Castle ActiveRecord 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 Castle ActiveRecord.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 89
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[18] Standards Mapping - FIPS200 SI
[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[23] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[24] Standards Mapping - OWASP Top 10 2010 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[42] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[43] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.dotnet.sql_injection_castleActiveRecord
Abstract
Usar o Hibernate para executar uma instrução SQL dinâmica construída com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado dessa instrução ou execute comandos SQL arbitrários.
Explanation
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 HQL.

Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta HQL 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 = "FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
List items = sess.createQuery(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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Hibernate API Documentation
[6] IDS00-J. Prevent SQL Injection CERT
[7] INJECT-2: Avoid dynamic SQL Oracle
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark partial
[14] Standards Mapping - Common Weakness Enumeration CWE ID 564
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2010 A1 Injection
[28] Standards Mapping - OWASP Top 10 2017 A1 Injection
[29] Standards Mapping - OWASP Top 10 2021 A03 Injection
[30] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[31] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[67] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.sql_injection_hibernate
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.



Mapas de Dados do iBatis permitem especificar parâmetros dinâmicos em instruções SQL e são normalmente definidos com o uso dos caracteres de #, da seguinte maneira:


<select id="getItems" parameterClass="MyClass" resultClass="items">
SELECT * FROM items WHERE owner = #userName#
</select>


Os caracteres # em torno do nome da variável indicam que iBatis irá criar uma consulta parametrizada com a variável userName. No entanto, iBatis também permite concatenar variáveis diretamente para instruções SQL usando caracteres $, abrindo a porta para SQL injection.

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.


<select id="getItems" parameterClass="MyClass" resultClass="items">
SELECT * FROM items WHERE owner = #userName# AND itemname = '$itemName$'
</select>


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 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 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 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 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 algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL Injection.
References
[1] iBatis Working with Data Maps
[2] iBatis Data Mapper Developer Guide
[3] S. J. Friedl SQL Injection Attacks by Example
[4] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[5] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[6] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[7] IDS00-J. Prevent SQL Injection CERT
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark partial
[14] Standards Mapping - Common Weakness Enumeration CWE ID 89
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2010 A1 Injection
[28] Standards Mapping - OWASP Top 10 2017 A1 Injection
[29] Standards Mapping - OWASP Top 10 2021 A03 Injection
[30] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[31] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.config.java.sql_injection_ibatis_data_map
Abstract
Usar a especificação JDO (Java Data Objects) para executar uma instrução SQL ou JDOQL dinâmica construída com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado dessa instrução ou execute comandos SQL arbitrários.
Explanation
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 ou JDOQL.

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 sql = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
Query query = pm.newQuery(Query.SQL, sql);
query.setClass(Person.class);
List people = (List)query.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 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.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] JDO API Documentation
[6] IDS00-J. Prevent SQL Injection CERT
[7] INJECT-2: Avoid dynamic SQL Oracle
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark partial
[14] Standards Mapping - Common Weakness Enumeration CWE ID 89
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2010 A1 Injection
[28] Standards Mapping - OWASP Top 10 2017 A1 Injection
[29] Standards Mapping - OWASP Top 10 2021 A03 Injection
[30] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[31] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.sql_injection_jdo
Abstract
A construção de uma instrução LINQ dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
Erros de injeção relacionados ao LINQ 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 LINQ 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 + "'";

var items = dataContext.ExecuteCommand<Item>(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 LINQ é 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 LINQ 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 LINQ. 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 LINQ pode ajudar, mas não tornará seu aplicativo seguro contra ataques de injeção de LINQ.

Outra solução comumente proposta para lidar com ataques de injeção de LINQ é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de injeção de LINQ, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de injeção de LINQ 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 LINQ.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 89
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[18] Standards Mapping - FIPS200 SI
[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[23] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[24] Standards Mapping - OWASP Top 10 2010 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[42] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[43] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.dotnet.sql_injection_linq
Abstract
A construção de uma instrução SQL dinâmica com a entrada proveniente de uma fonte não confiável pode permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários.
Explanation
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.



Arquivos XML de Mapeador do MyBatis permitem especificar parâmetros dinâmicos em instruções SQL e são normalmente definidos com o uso dos caracteres de #, da seguinte maneira:


<select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
SELECT *
FROM items
WHERE owner = #{userName}
</select>


O caractere # com colchetes em torno do nome da variável indica que MyBatis criará uma consulta parametrizada com a variável do userName. No entanto, MyBatis também permite concatenar variáveis diretamente para instruções SQL usando o caractere $, abrindo a porta para SQL injection.

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.


<select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
SELECT *
FROM items
WHERE owner = #{userName}
AND itemname = ${itemName}
</select>


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 deve 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 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 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 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 garantirá que seu aplicativo está 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 algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL Injection.
References
[1] MyBatis MyBatis 3 | Mapper XML Files
[2] MyBatis MyBatis 3 | Dynamic SQL
[3] S. J. Friedl SQL Injection Attacks by Example
[4] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[5] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[6] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[7] IDS00-J. Prevent SQL Injection CERT
[8] INJECT-2: Avoid dynamic SQL Oracle
[9] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[10] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[11] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[12] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[13] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[14] Standards Mapping - CIS Kubernetes Benchmark partial
[15] Standards Mapping - Common Weakness Enumeration CWE ID 89
[16] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[20] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[21] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[22] Standards Mapping - FIPS200 SI
[23] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[24] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[25] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[26] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[28] Standards Mapping - OWASP Top 10 2010 A1 Injection
[29] Standards Mapping - OWASP Top 10 2017 A1 Injection
[30] Standards Mapping - OWASP Top 10 2021 A03 Injection
[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[32] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[33] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[41] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[44] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[46] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[47] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[48] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[68] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[69] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[70] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.config.java.sql_injection_mybatis_mapper