Struts: Validator Without Form Field

Los campos de validación que no aparecen en los formularios con los que están asociados indican que la lógica de validación está desactualizada.

Es fácil para los desarrolladores olvidar actualizar la lógica de validación cuando realizan cambios en una clase de ActionForm. Una indicación de que la lógica de validación no se mantiene correctamente son las inconsistencias entre el formulario de acción y el formulario de validación.

Ejemplo 1.a: Un formulario de acción con dos 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;
    }
}

El ejemplo 1.a muestra un formulario de acción que tiene dos campos: startDate y endDate.

Ejemplo 1.b: Un formulario de validación con un tercer 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>

El ejemplo 1.b presenta un formulario de validación para el formulario de acción. El formulario de validación presenta un tercer campo: scale. La presencia del tercer campo sugiere que DateRangeForm se modificó sin tener en cuenta la validación.

Es de vital importancia que la lógica de validación se mantenga y se mantenga sincronizada con el resto de la aplicación. La entrada sin marcar es la causa principal de algunos de los problemas de seguridad de software peores y más comunes de la actualidad. Los ataques Cross-Site Scripting, SQL Injection y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la validación incorrecta o inexistente de entradas. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.