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.

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.

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.

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.

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.

Erros de SQL Injection ocorrem quando:

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

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

...
	string userName = ctx.GetAuthenticatedUserName();
	string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

A consulta pretende executar o seguinte código:

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

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

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

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

	SELECT * FROM items;

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

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

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

	DELETE FROM items;

	--'

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

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

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

	DELETE FROM items;

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

Uma abordagem tradicional para evitar ataques de injeção de SQL é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões de valores seguros, ou identificar e fazer o escape em uma lista de valores potencialmente mal-intencionados (lista de bloqueios). O confronto com uma lista de permissões pode ser um meio eficaz de impor regras de validação de entrada rigorosas, mas instruções SQL parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a implementação de uma lista de permissões é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL. Por exemplo, os invasores podem:

- Intencionar campos que não estejam entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas SQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL Injection.

Outra solução comumente proposta para lidar com ataques de SQL Injection é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de SQL Injection, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL Injection limitando os tipos de instruções que podem ser transmitidos a seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas instruções interessantes que ainda podem ser transmitidas para procedimentos armazenados. Mais uma vez, os procedimentos armazenados podem impedir alguns tipos de explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL Injection.

Injeção de SQL: Problemas de PartiQL ocorrem quando:

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

2. Os dados são usados para construir dinamicamente uma consulta PartiQL.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta PartiQL que procura itens correspondentes a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais owner corresponde ao nome do usuário autenticado no momento.

...
String userName = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...

A consulta pretende executar o seguinte código:

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

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

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

A adição da condição OR 'a'='a' faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:
Uma abordagem tradicional para evitar ataques de SQL injection é tratá-los como um problema de validação de entrada e, ou aceitar apenas caracteres de uma lista de permissão de valores seguros, ou identificar e escapar uma lista de valores possivelmente mal-intencionados. Verificar uma lista de permissões pode ser um meio muito eficaz de impor regras de validação de entrada rigorosas, mas instruções SQL parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a implementação de uma lista de negação é repleta de brechas que a tornam ineficaz na prevenção de ataques de SQL injection. Por exemplo, os invasores podem:

- Direcionar campos que não estão entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas PartiQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de injeção PartiQL.

Erros de SQL Injection ocorrem quando:

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

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

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

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

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

A consulta pretende executar o seguinte código:

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

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

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

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

        SELECT * FROM items;

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

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

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

        DELETE FROM items;

        --'

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

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

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

        DELETE FROM items;

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

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

Exemplo 3: O código a seguir adapta o Example 1 à plataforma Android.

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

Uma abordagem tradicional para evitar ataques de injeção de SQL é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões de valores seguros, ou identificar e fazer o escape em uma lista de valores potencialmente mal-intencionados (lista de bloqueios). O confronto com uma lista de permissões pode ser um meio muito eficaz de impor regras de validação de entrada rigorosas, mas instruções SQL parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a implementação de uma lista de permissões é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL. Por exemplo, os invasores podem:

- Intencionar campos que não estejam entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas SQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL Injection.

Outra solução comumente proposta para lidar com ataques de SQL Injection é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de SQL Injection, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL Injection limitando os tipos de instruções que podem ser transmitidos a seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas instruções interessantes que ainda podem ser transmitidas para procedimentos armazenados. Mais uma vez, os procedimentos armazenados podem impedir algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL Injection.

O uso de funções de codificação, como mysql_real_escape_string(), impedirá algumas vulnerabilidades de injeção de SQL, mas nem todas. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a injeção de SQL, podendo permitir que um invasor modifique o significado da instrução ou execute comandos SQL arbitrários. Como nem sempre é possível determinar de forma estática onde a entrada será exibida dentro de uma determinada seção de código interpretado dinamicamente, os rulepacks do Fortify Secure Coding podem apresentar dados SQL dinâmicos validados como problemas de “SQL Injection: Validação Insuficiente", mesmo que a validação possa ser suficiente para evitar a SQL Injection nesse contexto.

Erros de SQL injection ocorrem quando:

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



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

Exemplo 1: O exemplo a seguir demonstra como a configuração do banco de dados pode alterar o comportamento de mysqli_real_escape_string(). Quando o modo SQL está definido como "NO_BACKSLASH_ESCAPES", o caractere de barra invertida é tratado como um caractere normal, não como um caractere de escape[5]. Como mysqli_real_escape_string() leva isso em consideração, a consulta a seguir é vulnerável à SQL injection, pois " não tem mais o escape para \" devido à configuração do banco de dados.

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

Se o invasor deixar o campo password em branco e inserir " OR 1=1;-- para userName, as aspas não terão escape, e a consulta resultante será a seguinte:

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

Como OR 1=1 faz com que a cláusula where sempre seja avaliada como true e os hifens duplos fazem com que o resto da instrução seja tratado como um comentário, a consulta se torna equivalente à lógica de uma consulta muito mais simples:

  SELECT * FROM users;

Uma abordagem tradicional para evitar ataques de injeção de SQL é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões de valores seguros, ou identificar e fazer o escape em uma lista de valores potencialmente mal-intencionados (lista de bloqueios). O confronto com uma lista de permissões pode ser um meio muito eficaz de impor regras de validação de entrada rigorosas, mas instruções SQL parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a implementação de uma lista de permissões é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL. Por exemplo, os invasores podem:

- Intencionar campos que não estejam entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas SQL pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL injection.

Outra solução comumente proposta para lidar com ataques de SQL injection é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de SQL injection, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL injection limitando os tipos de instruções que podem ser transmitidos a seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas instruções interessantes que ainda podem ser transmitidas para procedimentos armazenados. Mais uma vez, os procedimentos armazenados podem impedir algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de SQL injection.

Erros de SQL Injection relacionados ao SubSonic ocorrem quando:

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

2. Os dados são usados para construir dinamicamente uma consulta.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta SubSonic que procura itens correspondentes a um nome especificado. A consulta restringe os itens exibidos àqueles nos quais owner corresponde ao nome do usuário autenticado no momento.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

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

A consulta pretende executar o seguinte código:

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

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

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

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

	SELECT * FROM items;

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

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

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

	DELETE FROM items;

	--'

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

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

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

	DELETE FROM items;

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

Uma abordagem tradicional para evitar ataques de injeção de SubSonic é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma lista de permissões com valores seguros, ou identificar e fazer o escape em uma lista de valores potencialmente mal-intencionados (lista de bloqueios). O confronto com uma lista de permissões pode ser um meio muito eficaz de impor regras de validação de entrada rigorosas, mas instruções SubSonic parametrizadas exigem menos manutenção e podem oferecer mais garantias no que diz respeito à segurança. Como é quase sempre o caso, a aplicação de uma lista de bloqueios é repleta de brechas que a tornam ineficaz na prevenção de ataques de injeção de SQL SubSonic. Por exemplo, os invasores podem:

- Intencionar campos que não estejam entre aspas
- Encontrar maneiras de contornar a necessidade de certos metacaracteres escapados
- Usar procedimentos armazenados para ocultar os metacaracteres injetados

O escape manual de caracteres na entrada para consultas SubSonic pode ajudar, mas não tornará seu aplicativo seguro contra ataques de SQL Injection SubSonic.

Outra solução comumente proposta para lidar com ataques de injeção de SubSonic é usar procedimentos armazenados. Embora os procedimentos armazenados evitem alguns tipos de ataques de injeção de SubSonic, eles não conseguem oferecer proteção contra muitos outros. Em geral, eles ajudam a evitar ataques de SQL Injection SubSonic limitando os tipos de instruções que podem ser transmitidos a seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas instruções interessantes que ainda podem ser transmitidas para procedimentos armazenados. Mais uma vez, os procedimentos armazenados podem impedir algumas explorações, mas não tornarão seu aplicativo seguro contra ataques de injeção de SubSonic.

Erros de terminação de cadeia de caracteres ocorrem quando:

1. Os dados entram em um programa por meio de uma função que encerra sua saída com valor nulo.

2. Os dados são transmitidos para uma função que requer que sua entrada tenha terminação nula.
Exemplo 1: O código a seguir faz a leitura de cfgfile e copia a entrada em inputbuf usando strcpy(). Esse código presume erroneamente que inputbuf sempre conterá um terminador nulo.

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

O código no Example 1 se comportará corretamente se os dados lidos de cfgfile tiverem uma terminação nula no disco, conforme o esperado. Porém, se um invasor puder modificar essa entrada de forma que ela não contenha o caractere null esperado, a chamada para strcpy() continuará copiando da memória até encontrar um caractere null arbitrário. Isso provavelmente estourará o buffer de destino e, se o invasor puder controlar o conteúdo da memória imediatamente depois de inputbuf, isso poderá deixar o aplicativo suscetível a um ataque de estouro de buffer.

Exemplo 2: No código a seguir, readlink() expande o nome de um link simbólico armazenado no buffer path, de forma que o buffer buf contenha o caminho absoluto do arquivo referenciado por esse link simbólico. O comprimento do valor resultante é então calculado com o uso de strlen().

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

O código no Example 2 não se comportará corretamente, pois o valor lido em buf por readlink() não terá terminação nula. Em situações de teste, vulnerabilidades como esta podem não ser capturadas, pois o conteúdo não utilizado de buf e a memória imediatamente depois dele podem ser null, fazendo assim com que strlen() pareça estar se comportando corretamente. No entanto, em condições naturais, strlen() continuará a atravessar a memória até encontrar um caractere null arbitrário na pilha, o que resulta em um valor de length que é muito superior ao tamanho de buf e pode causar um estouro de buffer em usos subsequentes desse valor.

Exemplo 3: O código a seguir usa snprintf() para copiar uma string de entrada do usuário e colocá-la em várias strings de saída. Apesar de fornecer barreiras de proteção adicionais em comparação com sprintf(), principalmente a especificação de um tamanho máximo de saída, a função snprintf() ainda é suscetível a um erro de terminação de string quando o tamanho de saída especificado é maior que a entrada potencial. Erros de terminação de string podem levar a problemas posteriores, como vazamento de memória ou estouro de buffer.

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

O código no Example 3 demonstra um vazamento de memória. Quando a output_2 for populada com no_null_term, snprintf() deverá ler a partir da localização de no_null_term até que um caractere nulo seja encontrado ou o limite de tamanho especificado seja atingido. Porque não há terminação em no_null_term, snprintf continua a ler os dados de output_1, em que eventualmente atinge um caractere de terminação nulo fornecido pela primeira chamada de snprintf(). O vazamento de memória é demonstrado pela printf() daoutput_2, que contém a sequência de caracteres de no_null_term duas vezes.

Tradicionalmente, as cadeias de caracteres são representadas como uma região de memória contendo dados que terminam com um caractere null. Métodos mais antigos de manipulação de cadeias de caracteres dependem frequentemente desse caractere null para determinar o comprimento da cadeia de caracteres. Se um buffer que não contém um terminador nulo for transmitido para uma dessas funções, a função fará uma leitura além do final do buffer.

Usuários mal-intencionados normalmente exploram esse tipo de vulnerabilidade por meio da injeção de dados com tamanho ou conteúdo inesperado no aplicativo. Eles podem fornecer a entrada mal-intencionada diretamente como entrada para o programa ou indiretamente modificando os recursos do aplicativo, como arquivos de configuração. Se um invasor fizer com que o aplicativo leia além dos limites de um buffer, ele talvez seja capaz de usar um buffer overflow resultante para injetar e executar código arbitrário no sistema.

Um ou mais Campos de Ação não têm uma definição de validação correspondente. Cada campo deve ter uma rotina de validação explícita referenciada em ActionClass-validation.xml.

É fácil os desenvolvedores se esquecerem de atualizar a lógica de validação ao removerem ou renomearem mapeamentos de formulário de ação. Uma indicação de que a lógica de validação não está sendo mantida adequadamente é a ausência de uma definição de validador.

É extremamente importante que a lógica de validação seja mantida e permaneça em sincronia com o restante do aplicativo. Entradas não verificadas são a causa raiz de alguns dos piores e mais comuns problemas de segurança de software atuais. Vulnerabilidades de Cross-Site Scripting, SQL Injection e controle de processos são todas derivadas de validações de entradas incompletas ou ausentes. Embora aplicativos J2EE não sejam geralmente suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE fizer interface com um código nativo que não realiza verificações de limites de matriz, um invasor poderá ser capaz de utilizar um erro de validação de entrada nesse aplicativo J2EE para lançar um ataque de buffer overflow.

Existe mais de uma definição de validador de campo com o mesmo nome em ActionClass-validation.xml. Definições de validação duplicadas com o mesmo nome podem resultar em comportamento inesperado.

Exemplo 1: A entrada a seguir mostra duas definições de validador de campo duplicadas.

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

É extremamente importante que a lógica de validação seja mantida e sincronizada com o restante do aplicativo. A entrada não verificada é a causa raiz de alguns dos piores e mais comuns problemas de segurança de software da atualidade. Vulnerabilidades de criação de script entre sites, SQL injection e controle de processos são todas derivadas de manipulações de entradas incompletas ou ausentes. Embora os aplicativos J2EE geralmente não sejam suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE faz interface com o código nativo que não executa a verificação de limite de array, um invasor pode ser capaz de usar um erro de validação de entrada no aplicativo J2EE para lançar um ataque de estouro de buffer (buffer overflow).

Mais de um arquivo ActionClass-validation.xml foi descoberto para essa definição de Ação do Struts2. Para cada Ação do Struts2 definida no formato de ActionClass, o Struts2 procura um arquivo ActionClass-validation.xml correspondente para as restrições de validação necessárias. Ter várias definições de validação para uma Ação incluída na implantação pode resultar em um comportamento inesperado.

Se dois formulários de validação tiverem o mesmo nome, o Validador de Struts escolherá arbitrariamente um deles a ser usado para validação de entradas, descartando o outro. Essa decisão pode não corresponder às expectativas do programador. Além disso, ela indica que a lógica de validação não está sendo mantida e pode indicar que outros erros de validação mais sutis estão presentes.

É extremamente importante que a lógica de validação seja mantida e permaneça em sincronia com o restante do aplicativo. Entradas não verificadas são a causa raiz de alguns dos piores e mais comuns problemas de segurança de software atuais. Vulnerabilidades de Cross-Site Scripting, SQL Injection e controle de processos são todas derivadas de validações de entradas incompletas ou ausentes. Embora aplicativos J2EE não sejam geralmente suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE fizer interface com um código nativo que não realiza verificações de limites de matriz, um invasor poderá ser capaz de utilizar um erro de validação de entrada nesse aplicativo J2EE para lançar um ataque de buffer overflow.

Mais de uma definição de validador foi descoberta em validators.xml. Várias definições de validação com o mesmo nome podem resultar em comportamento inesperado.

Se duas classes de validação são definidas com o mesmo nome, o Struts Validator escolhe arbitrariamente um dos formulários para usar para validação de entrada e descarta o outro. Esta decisão pode não corresponder às expectativas do programador. Além disso, indica que a lógica de validação não está sendo mantida e pode indicar que outros erros de validação mais sutis estejam presentes.

É extremamente importante que a lógica de validação seja mantida e sincronizada com o restante do aplicativo. A entrada não verificada é a causa raiz de alguns dos piores e mais comuns problemas de segurança de software da atualidade. Vulnerabilidades de criação de script entre sites, SQL injection e controle de processos são todas derivadas de manipulações de entradas incompletas ou ausentes. Embora os aplicativos J2EE geralmente não sejam suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE faz interface com o código nativo que não executa a verificação de limite de array, um invasor pode ser capaz de usar um erro de validação de entrada no aplicativo J2EE para lançar um ataque de estouro de buffer (buffer overflow).

O Struts2 exige que validadores personalizados sejam definidos em validators.xml antes de serem usados em uma definição do validador de Ação. As definições do validador ausentes são uma indicação de que a validação não está atualizada.

Exemplo 1: O seguinte validador de Ação não foi definido em validators.xml.

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

É extremamente importante que a lógica de validação seja mantida e sincronizada com o restante do aplicativo. A entrada não verificada é a causa raiz de alguns dos piores e mais comuns problemas de segurança de software da atualidade. Vulnerabilidades de criação de script entre sites, SQL injection e controle de processos são todas derivadas de manipulações de entradas incompletas ou ausentes. Embora os aplicativos J2EE geralmente não sejam suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE faz interface com o código nativo que não executa a verificação de limite de array, um invasor pode ser capaz de usar um erro de validação de entrada no aplicativo J2EE para lançar um ataque de estouro de buffer (buffer overflow).

Entradas não verificadas são a principal causa de vulnerabilidades em aplicativos J2EE. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control e SQL injection. Embora aplicativos J2EE não sejam geralmente suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE fizer interface com um código nativo que não realiza verificações de limites de matriz, um invasor poderá ser capaz de utilizar um erro de validação de entrada nesse aplicativo J2EE para lançar um ataque de buffer overflow.

Para evitar esses ataques, use a estrutura de Validação de Struts para verificar todas as entradas do programa antes que elas sejam processadas pelo aplicativo. Use o Fortify Static Code Analyzer para garantir que não haja lacunas na sua configuração do Validador de Struts.

Exemplos de uso do validador incluem verificações para garantir que:

- Campos de número de telefone contenham somente caracteres válidos em números de telefone

- Valores boolianos sejam apenas "T" ou "F"

- Strings de forma livre tenham um comprimento e uma composição razoáveis

Um arquivo de validação do Struts2 foi descoberto sem uma ação correspondente do Struts2. Para cada ActionClass, o Struts2 procura um ActionClass-validation.xml correspondente para as restrições de validação necessárias. Neste caso, um arquivo de validação na forma de ActionClass-validation.xml foi encontrado, mas a ActionClass não corresponde a uma Ação definida no arquivo de configuração do Struts2.

É fácil para os desenvolvedores esquecerem de atualizar a lógica de validação ao remover ou renomear mapeamentos de formulários de ação. Uma indicação de que a lógica de validação não está sendo mantida adequadamente é a presença de um formulário de validação não utilizado.

Uma definição do Struts2 Validator refere-se a um campo de ação que não existe.

É fácil para os desenvolvedores esquecerem de atualizar a lógica de validação ao remover ou renomear mapeamentos de formulários de ação. Uma indicação de que a lógica de validação não está sendo mantida adequadamente é a presença de uma definição de validador órfã.

Se dois formulários de validação tiverem o mesmo nome, o Struts Validator escolhe arbitrariamente um dos formulários para usar para validação de entrada e descarta o outro. Esta decisão pode não corresponder às expectativas do programador. Além disso, indica que a lógica de validação não está sendo mantida e pode indicar que outros erros de validação mais sutis estejam presentes.

Exemplo 1: Dois formulários de validação com o mesmo nome.

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

É extremamente importante que a lógica de validação seja mantida e sincronizada com o restante do aplicativo. A entrada não verificada é a causa raiz de alguns dos piores e mais comuns problemas de segurança de software da atualidade. Vulnerabilidades de criação de script entre sites, SQL injection e controle de processos são todas derivadas de manipulações de entradas incompletas ou ausentes. Embora os aplicativos J2EE geralmente não sejam suscetíveis a ataques de corrupção de memória, se um aplicativo J2EE faz interface com o código nativo que não executa a verificação de limite de array, um invasor pode ser capaz de usar um erro de validação de entrada no aplicativo J2EE para lançar um ataque de estouro de buffer (buffer overflow).