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.

Qualquer servidor que contenha informações confidenciais ou funcionalidades privilegiadas, como um painel de administração remota, deverá exigir autenticação para acesso. Se esse não for o caso, um invasor poderá roubar informações confidenciais ou assumir o controle de um host alvo simplesmente adivinhando nomes de usuários comuns.

O cliente pode usar o método de autenticação NoneAuth para determinar os métodos de autenticação disponíveis.

Exemplo 1: O código Paramiko a seguir tenta se autenticar no servidor usando a solicitação de autenticação "none".

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

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.

O Apache Struts 2.x inclui as novas interfaces Aware para permitir que desenvolvedores injetem mapas facilmente com informações de tempo de execução relevantes em seus códigos de Ações. Essas interfaces incluem: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware e org.apache.struts2.interceptor.RequestAware. Para que qualquer um desses mapas de dados seja injetado em seus códigos de Ações, os desenvolvedores precisam implementar o setter especificado na interface (por exemplo: setSession para a Interface SessionAware):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

Por outro lado, o Struts 2.x associa automaticamente os dados de solicitações provenientes do usuário às propriedades da Ação por meio de assessores públicos definidos na Ação. Como as interfaces Aware exigem a implementação do setter público definido na interface Aware, esse setter também será automaticamente associado a qualquer parâmetro de solicitação que corresponder ao nome do setter da interface Aware, o que pode permitir que invasores remotos modifiquem valores de dados em tempo de execução através de um parâmetro trabalhado para um aplicativo que implementa uma interface afetada, conforme demonstrado pelas interfaces SessionAware, RequestAware e ApplicationAware.

A URL a seguir permitirá que um atacante substitua o atributo "roles" no mapa de sessão. Isso pode acabar permitindo que o invasor se torne um administrador.

http://server/VulnerableAction?session.roles=admin


Embora essas interfaces só exijam a implementação dos assessores setter, se o getter correspondente também for implementado, as alterações nessas coleções de mapas terão o escopo definido para a sessão, em vez de somente afetarem o escopo da solicitação atual.

O Struts 2 introduziu um recurso chamado “Invocação de método dinâmico", que permite que uma Ação exponha métodos diferentes de execute(). O caractere ! (exclamação) ou o prefixo method: pode ser usado na URL da Ação para invocar qualquer método público nessa Ação quando a “Invocação de método dinâmico" está habilitada. Os desenvolvedores que não estiverem cientes desse recurso poderão inadvertidamente expor a lógica de negócios interna aos invasores.

Como exemplo, se a Ação contiver um método público chamado getUserPassword(), que não usa argumentos e não consegue desabilitar o recurso "Invocação de Métodos Dinâmica", um invasor será capaz de tirar proveito disso visitando a seguinte URL: http://server/app/recoverpassword!getPassword.action

O Apache Struts 2.x inclui as novas interfaces Aware para permitir que desenvolvedores injetem mapas facilmente com informações de tempo de execução relevantes em seus códigos de Ações. Essas interfaces incluem: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware e org.apache.struts2.interceptor.RequestAware. Para que qualquer um desses mapas de dados seja injetado em seus códigos de Ações, os desenvolvedores precisam implementar o setter especificado na interface (por exemplo: setSession para a Interface SessionAware):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

Por outro lado, o Struts 2.x associa automaticamente os dados de solicitações provenientes do usuário às propriedades da Ação por meio de assessores públicos definidos na Ação. Como as interfaces Aware exigem a implementação do setter público definido na interface Aware, esse setter também será automaticamente associado a qualquer parâmetro de solicitação que corresponder ao nome do setter da interface Aware, o que pode permitir que invasores remotos modifiquem valores de dados em tempo de execução através de um parâmetro trabalhado para um aplicativo que implementa uma interface afetada, conforme demonstrado pelas interfaces SessionAware, RequestAware e ApplicationAware.

A URL a seguir permitirá que um atacante substitua o atributo "roles" no mapa de sessão. Isso pode acabar permitindo que o invasor se torne um administrador.

http://server/VulnerableAction?session.roles=admin


Embora essas interfaces só exijam a implementação dos assessores setter, se o getter correspondente também for implementado, as alterações nessas coleções de mapas terão o escopo definido para a sessão, em vez de somente afetarem o escopo da solicitação atual.

O Apache Struts 2.x inclui as novas interfaces Aware para permitir que desenvolvedores injetem mapas facilmente com informações de tempo de execução relevantes em seus códigos de Ações. Essas interfaces incluem: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware e org.apache.struts2.interceptor.RequestAware. Para que qualquer um desses mapas de dados seja injetado em seus códigos de Ações, os desenvolvedores precisam implementar o setter especificado na interface (por exemplo: setSession para a Interface SessionAware):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

Por outro lado, o Struts 2.x associa automaticamente os dados de solicitações provenientes do usuário às propriedades da Ação por meio de assessores públicos definidos na Ação. Como as interfaces Aware exigem a implementação do setter público definido na interface Aware, esse setter também será automaticamente associado a qualquer parâmetro de solicitação que corresponder ao nome do setter da interface Aware, o que pode permitir que invasores remotos modifiquem valores de dados em tempo de execução através de um parâmetro trabalhado para um aplicativo que implementa uma interface afetada, conforme demonstrado pelas interfaces SessionAware, RequestAware e ApplicationAware.

A URL a seguir permitirá que um atacante substitua o atributo "roles" no mapa de sessão. Isso pode acabar permitindo que o invasor se torne um administrador.

http://server/VulnerableAction?session.roles=admin


Embora essas interfaces só exijam a implementação dos assessores setter, se o getter correspondente também for implementado, as alterações nessas coleções de mapas terão o escopo definido para a sessão, em vez de somente afetarem o escopo da solicitação atual.

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

Nomes duplicados de form-bean não têm qualquer utilidade, pois apenas a última entrada será registrada quando o mesmo nome é usado em várias tags <form-bean>.

Exemplo 1: A seguinte configuração tem duas entradas form-bean com o mesmo nome.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

O Struts usa o atributo path para localizar o recurso necessário para lidar com uma solicitação. Como o caminho é uma localização relativa ao módulo, é um erro se não começar com um caractere "/".

Exemplo 1: A configuração a seguir contém um caminho em branco.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

Exemplo 2: A configuração a seguir usa um caminho que não começa com um caractere "/".

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

A especificação de struts exige um atributo input sempre que uma ação nomeada retorna erros de validação [2]. O atributo input especifica a página usada para exibir mensagens de erro quando ocorrem erros de validação.
Exemplo 1: A configuração a seguir define uma ação de validação nomeada, mas não especifica um atributo input.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>