Difference between revisions of "Improper Data Validation"

Revision as of 00:47, 18 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by

ASDR Table of Contents

Last revision (mm/dd/yy): 02/18/2009

Description

Struts: Duplicate Validation Forms

Multiple validation forms with the same name indicate that validation logic is not up-to-date.

If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present.

Example

Two validation forms with the same name.

	<form-validation>
		<formset>
			<form name="ProjectForm">
			...
			</form>
			<form name="ProjectForm">
			...
			</form>
		</formset>
	</form-validation>

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

Struts: Erroneous validate() Method

The validator form defines a validate() method but fails to call super.validate().

The Struts Validator uses a form's code>validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework:

	ValidatorForm
	ValidatorActionForm
	DynaValidatorForm
	DynaValidatorActionForm

If you create a class that extends one of these classes and if your class implements custom validation logic by overriding the validate() method, you must call super.validate() in your validate() implementation. If you do not, the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form.

Disabling the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. 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.

Risk Factors

TBD

Examples

Related Attacks

• Attack 1
• Attack 2

Related Vulnerabilities

• Vulnerability 1
• Vulnerabiltiy 2

Related Controls

• Category:Input Validation

Related Technical Impacts

• Technical Impact 1
• Technical Impact 2

References

TBD