A tag <exception> exige que um tipo de exceção seja definido. Um atributo type ausente ou em branco é indicativo de um manipulador de exceção supérfluo ou uma omissão acidental. Se um desenvolvedor pretendia lidar com uma exceção, mas se esqueceu de definir o tipo de exceção, o aplicativo pode vazar informações confidenciais sobre o sistema.
Exemplo 1: A configuração a seguir omite o tipo da tag <exception>.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

O Struts usa entradas form-bean para mapear formulários HTML para ações. Se o atributo name em uma tag <action> não corresponde ao nome de uma form-bean , a ação não pode ser mapeada e indica uma definição supérflua ou um erro tipográfico.

Exemplo 1: A configuração a seguir não contém um mapeamento para bean2 .

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

O Struts usa o nome form-bean para mapear formulários HTML para ações. Se uma form-bean não tem um nome, não pode ser mapeado para uma ação e indica uma definição supérflua ou uma bean omitida acidentalmente.
Aqui está um exemplo adequado de form-bean:
Exemplo 1: A seguinte form-bean tem um atributo de name vazio.

<form-beans>
  <form-bean name="" 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-beans>

O Struts usa entradas form-bean para mapear formulários HTML para ações. Se uma form-bean não tem um tipo, não pode ser mapeada para uma ação.
Exemplo 1: A seguinte form-bean tem um atributo de type vazio.

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

O Struts exige que as tags <form-property> incluam um atributo type. O Struts lançará uma exceção ao processar um formulário que define uma form-property sem tipo.

Exemplo 1: A seguinte configuração omite um tipo para a propriedade name.

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

Uma tag <forward> deve ter os atributos name e path. Sem um nome, forward nunca será usado.

Exemplo 1: A seguinte tag <forward> tem um atributo de name vazio.

    <forward name="" path="/results.jsp"/>

Uma tag <forward> deve ter os atributos name e path. É um erro omitir um caminho ou especificar um caminho em branco. Além disso, todos os caminhos devem começar com o caractere "/".

Exemplo 1: A seguinte tag <forward> tem um atributo de path ausente.

    <forward name="success" />

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

O Validador de Struts usa o método validate() de um formulário para verificar o conteúdo das propriedades do formulário em relação às restrições especificadas no formulário de validação associado. Isso significa que as seguintes classes têm um método validate() que faz parte da estrutura de validação:

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

Se você criar uma classe que estende uma dessas classes e se a sua classe implementar a lógica de validação personalizada substituindo o método validate(), você deverá chamar super.validate() na sua implementação validate(). Em caso negativo, a Estrutura de Validação não poderá verificar o conteúdo do formulário com base em um formulário de validação. Em outras palavras, a estrutura de validação será desabilitada para o formulário especificado.

Desabilitar a estrutura de validação de um formulário expõe o aplicativo a vários tipos de ataques. Entradas não verificadas resultam são a causa raiz de vulnerabilidades, como criação de scripts entre sites, controle de processos 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 usar o Struts Validator, um formulário deve estender um dos seguintes:

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

Você deve estender uma dessas classes porque o Struts Validator se conecta ao seu aplicativo implementando o método validate() nessas classes.

Os formulários derivados das seguintes classes não podem usar o Validador Struts:

ActionForm
DynaActionForm

Ignorar a estrutura de validação de um formulário expõe o aplicativo a vários tipos de ataques. A entrada não verificada é a causa raiz de vulnerabilidades como cross-site scripting, controle de processo e SQL injection. 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).

Omitir a validação até mesmo para um único campo de entrada pode permitir que os invasores tenham a margem de manobra de que precisam.

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

Alguns aplicativos usam o mesmo ActionForm para mais de uma finalidade. Em situações como essa, alguns campos podem não ser utilizados em certos mapeamentos de ações. É fundamental que campos não utilizados também sejam validados. De preferência, esses campos não utilizados devem ser restritos de forma a poderem ser apenas vazios ou não definidos. Se os campos não utilizados não forem validados, a lógica de negócios compartilhada em uma ação pode permitir que os invasores se esquivem das verificações de validação que são realizadas para outros usos do formulário.

A entrada não verificada é a principal causa de vulnerabilidades em aplicativos J2EE. A entrada não verificada pode levar a inúmeras vulnerabilidades, incluindo cross-site scripting, controle de processo e SQL injection. 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).

Para evitar tais ataques, use o Struts Validator para verificar todas as entradas do programa antes delas serem processadas pelo aplicativo. Use o Fortify Static Code Analyzer para garantir que não haja buracos na configuração do Struts Validator.

Os exemplos de uso do validador incluem a verificação para garantir que:

- Os campos de número de telefone contêm apenas caracteres válidos em números de telefone

- Os valores booleanos são apenas "T" ou "F"

- Cadeias de caracteres de forma livre têm tamanho e composição razoáveis

O Struts usa entradas form-bean para mapear formulários HTML para ações. Se o elemento <action-mappings> do arquivo de configuração do Struts não contém uma entrada que corresponda a um formulário de ação relevante definido por meio de uma tag <form-bean>, a lógica do aplicativo pode não estar atualizada.

Exemplo 1: A configuração a seguir não contém um mapeamento para bean2 .

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean1" />
  <form-bean name="bean2" type="coreservlets.UserFormBean2" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
</action-mappings>

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

Se um mapeamento de formulário de ação do Struts especifica um formulário, ele deve ter um formulário de validação definido no Validador de Struts. Se um mapeamento de formulário de ação não tiver um formulário de validação definido, ele pode ser vulnerável a vários ataques que exploram uma entrada não verificada.

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

Uma ação ou um formulário pode executar a validação de outras maneiras, mas o Struts Validator fornece uma excelente maneira de verificar se todas as entradas recebem pelo menos um nível básico de verificação. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Um mapeamento de formulário de ação nunca deve desabilitar a validação. Desativar a validação desativa o Validador Struts, bem como qualquer lógica de validação personalizada realizada pelo formulário.

Exemplo 1: Um mapeamento de formulário de ação que desativa a validação.

<action path="/download"
type="com.website.d2.action.DownloadAction"
name="downloadForm"
scope="request"
input=".download"
validate="false">
</action>

A desativação da validação expõe essa ação a vários tipos de ataques. A entrada não verificada é a causa raiz de vulnerabilidades como cross-site scripting, controle de processo e SQL injection. 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).

É fácil para os desenvolvedores esquecerem de atualizar a lógica de validação quando fazem alterações em uma classe ActionForm. Uma indicação de que a lógica de validação não está sendo mantida adequadamente são as inconsistências entre o formulário de ação e o formulário de validação.

Exemplo 1.a: Um formulário de ação com dois campos.

    public class DateRangeForm extends ValidatorForm {
    String startDate, endDate;
    public void setStartDate(String startDate) {
        this.startDate = startDate;
    }
    public void setEndDate(String endDate) {
        this.endDate = endDate;
    }
}

O exemplo 1.a mostra um formulário de ação que possui dois campos, sendo startDate e endDate .

Exemplo 1.b: Um formulário de validação com um terceiro campo.

<form name="DateRangeForm">
    <field property="startDate" depends="date">
        <arg0 key="start.date"/>
    </field>
    <field property="endDate" depends="date">
         <arg0 key="end.date"/>
    </field>
    <field property="scale" depends="integer">
         <arg0 key="range.scale"/>
    </field>
</form>

O exemplo 1.b lista um formulário de validação para o formulário de ação. O formulário de validação lista um terceiro campo: scale. A presença do terceiro campo sugere que a DateRangeForm foi modificada sem levar em consideração a validação.

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

Os campos do sistema ABAP estão sempre disponíveis em programas ABAP. O sistema de tempo de execução os preenche de acordo com o contexto depois de iniciar um programa, enviar uma tela e alterar o modo interno. Eles podem então ser usados em programas para consultar o status do sistema. Os campos do sistema são variáveis, mas sempre devem ser somente leitura e tratados como se fossem constantes. Alterar seus valores pode provocar a perda de informações importantes que são necessárias para o fluxo do programa. Apenas alguns deles podem ser modificados dentro de programas ABAP do cliente.


Alterar valores de campos do sistema que comunicam informações específicas de tempo de execução ao programa ABAP pode causar interrupções ou comportamentos inesperados nesse programa.

Um vazamento de informações ocorre quando dados do sistema ou informações de depuração deixam o programa por meio de um fluxo de saída ou de uma função de registro em log.

Exemplo 1: O código a seguir grava uma exceção no fluxo de erro padrão:

try {
    ...
} catch (Exception e) {
    e.printStackTrace();
}

Dependendo da configuração do sistema, essas informações podem ser despejadas em um console, gravadas em um arquivo de log ou expostas para um usuário remoto. Por exemplo, com mecanismos de script, é comum redirecionar as informações de saída de "Erro padrão" ou "Saída padrão" para um arquivo ou outro programa. Como alternativa, o sistema no qual o programa é executado pode ter um mecanismo de registro em log remoto, como um servidor "syslog", que envia os logs para um dispositivo remoto. Durante o desenvolvimento, não há como saber onde essas informações podem acabar sendo exibidas.

Em alguns casos, a mensagem de erro fornece ao invasor o tipo exato de ataque ao qual o sistema está vulnerável. Por exemplo, uma mensagem de erro de banco de dados pode revelar que o aplicativo é vulnerável a um ataque de injeção de SQL. Outras mensagens de erro podem revelar pistas mais indiretas sobre o sistema. No Example 1, as informações vazadas podem implicar informações sobre o tipo de sistema operacional, os aplicativos instalados no sistema e a quantidade de cuidado que os administradores dedicaram à configuração do programa.

O vazamento de informações também é uma preocupação em um ambiente de computação móvel. Com plataformas móveis, os aplicativos são baixados de várias fontes e são executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta e é por isso que os autores de aplicativos precisam ser cuidadosos a respeito de quais informações eles incluem em mensagens endereçadas a outros aplicativos em execução no dispositivo.

Exemplo 2: O código a seguir transmite o rastreamento de pilha de uma exceção detectada para todos os receptores Android registrados.

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

Este é outro cenário específico ao ambiente móvel. A maioria dos dispositivos móveis agora implementa um protocolo NFC (Near-Field Communication) para o rápido compartilhamento de informações entre dispositivos que utilizam a comunicação por rádio. Ele funciona aproximando os dispositivos ou fazendo com que eles se toquem. Mesmo que o alcance de comunicação do NFC esteja limitado a apenas alguns centímetros, espionagens, modificação de dados e vários outros tipos de ataques são possíveis, já que o NFC, por si só, não garante a comunicação segura.

Exemplo 3: A plataforma Android fornece suporte para NFC. O código a seguir cria uma mensagem que é enviada ao outro dispositivo dentro do intervalo.

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

Uma mensagem NDEF (NFC Data Exchange Format) contém dados com tipos definidos, um URI ou uma carga de aplicativo personalizada. Se a mensagem contiver informações sobre o aplicativo, como seu nome, tipo MIME ou versão de software do dispositivo, essas informações poderão vazar para um intruso.

Um vazamento de informações ocorre quando dados do sistema ou informações de depuração deixam o programa por meio de um fluxo de saída ou de uma função de registro em log.



Quando definido como true, axis.enableListQuery permite a listagem do Web Service Deployment Descriptor (WSDD). Este recurso expõe a configuração atual do sistema, que contém informações confidenciais, como a senha do adminservice.