This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Struts: Validator Without Form Field"

From OWASP
Jump to: navigation, search
 
(Contents provided by Fortify.)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 +
{{Template:Fortify}}
 +
 +
==Abstract==
 +
 +
Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
  
 
==Description==
 
==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.
  
 
==Examples ==
 
==Examples ==
 +
 +
===Example 1===
 +
 +
An action form with two fields.
 +
 +
<pre>
 +
public class DateRangeForm extends ValidatorForm {
 +
String startDate, endDate;
 +
public void setStartDate(String startDate) {
 +
this.startDate = startDate;
 +
}
 +
public void setEndDate(String endDate) {
 +
this.endDate = endDate;
 +
}
 +
}
 +
</pre>
 +
 +
Example 1 shows an action form that has two fields, startDate and endDate.
 +
 +
===Example 2===
 +
 +
A validation form with a third field.
 +
 +
<pre>
 +
<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>
 +
</pre>
 +
 +
Example 2 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.
 +
 +
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.
  
 
==Related Threats==
 
==Related Threats==
Line 12: Line 59:
  
 
==Related Countermeasures==
 
==Related Countermeasures==
 +
 +
[[:Category:Input Validation]]
  
 
==Categories==
 
==Categories==
 
{{Template:Stub}}
 
  
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Input Validation Vulnerability]]
 
 
[[Category:Struts]]
 
[[Category:Struts]]
 +
[[Category:Java]]
 +
[[Category:Code Snippet]]
 +
[[Category:Implementation]]

Revision as of 18:26, 24 July 2006

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

This article includes content generously donated to OWASP by MicroFocus Logo.png

Abstract

Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.

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.

Examples

Example 1

An action form with two fields.

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

Example 1 shows an action form that has two fields, startDate and endDate.

Example 2

A validation form with a third field.

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

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

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.

Related Threats

Related Attacks

Related Vulnerabilities

Related Countermeasures

Category:Input Validation

Categories