Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
Extended Description
It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form.
Time of Introduction
Implementation
Operation
Applicable Platforms
Languages
Java
Common Consequences
Scope
Effect
Other
Technical Impact: Other
It is critically important that validation logic be maintained and
kept in sync with the rest of the application. Unchecked input is the
root cause of some of today's worst and most common software security
problems. Cross-site scripting, SQL injection, and process control
vulnerabilities all stem from incomplete or absent input validation.
Demonstrative Examples
Example 1
An action form with two fields.
(Bad Code)
Example
Language: Java
public class DateRangeForm extends ValidatorForm {
String startDate, endDate;
public void setStartDate(String startDate) {
this.startDate = startDate;
}
public void setEndDate(String endDate) {
this.endDate = endDate;
}
}
This example shows an action form that has two fields, startDate and
endDate.
Example 2
A validation form with a third field.
(Bad Code)
Example
Language: XML
<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>
This example lists a validation form for the action form. The
validation form lists a third field: scale. The presence of the third
field suggests that DateRangeForm was modified without taking validation
into account.
Potential Mitigations
Phases: Build and Compilation; Testing
Strategy: Input Validation
To find the issue in the implementation, manual checks or automated
static analysis could be applied to the xml configuration files.
Other Notes
Although J2EE applications are not generally susceptible to memory
corruption attacks, if a J2EE application interfaces with native code that
does not perform array bounds checking, an attacker may be able to use an
input validation mistake in the J2EE application to launch a buffer overflow
attack.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Description
