Struts: Validator Without Form Field

Os campos de validação que não aparecem nos formulários aos quais estão associados indicam que a lógica de validação está desatualizada.

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