Improper Data Validation - Revision history

Imifos: page category

2016-02-02T14:33:40Z

page category

Imifos: fixing category

2015-12-01T13:04:52Z

fixing category

Laurent.B: TOC added

2015-06-15T10:41:31Z

TOC added

Laurent.B: code ident

2015-06-15T10:36:53Z

code ident

KirstenS at 01:17, 21 February 2009

2009-02-21T01:17:22Z

KirstenS at 02:27, 18 February 2009

2009-02-18T02:27:37Z

KirstenS: /* Struts: Validator Turned Off */

2009-02-18T01:19:08Z

‎Struts: Validator Turned Off

KirstenS: /* Editing Struts: Validator Turned Off */

2009-02-18T01:16:57Z

‎Editing Struts: Validator Turned Off

KirstenS: /* Struts: Unvalidated Action Form */

2009-02-18T01:15:38Z

‎Struts: Unvalidated Action Form

KirstenS: /* Struts: Unused Validation Form */

2009-02-18T01:11:16Z

‎Struts: Unused Validation Form

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
 [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
@@ Line 219: / Line 218: @@
 [[Category:Input Validation Vulnerability]]
 [[Category:Struts]]
-[[Category:OWASP Java Project]]
+[[Category:Java]]
 [[Category:Code Snippet]]
 [[Category:Implementation]]
 [[Category:Vulnerability]]

@@ Line 219: / Line 219: @@
 [[Category:Input Validation Vulnerability]]
 [[Category:Struts]]
-[[Category:Java]]
+[[Category:OWASP Java Project]]
 [[Category:Code Snippet]]
 [[Category:Implementation]]
 [[Category:Vulnerability]]

← Older revision		Revision as of 10:41, 15 June 2015
Line 5:		Line 5:

	[[ASDR_TOC_Vulnerabilities\|Vulnerabilities Table of Contents]]		[[ASDR_TOC_Vulnerabilities\|Vulnerabilities Table of Contents]]
		+
		+	__TOC__

	==Description==		==Description==

@@ Line 140: / Line 140: @@
 <pre>
-		public class DateRangeForm extends ValidatorForm {
+	public class DateRangeForm extends ValidatorForm {
 		String startDate, endDate;
 		public void setStartDate(String startDate) {

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==

← Older revision		Revision as of 02:27, 18 February 2009
Line 3:		Line 3:

	[[ASDR Table of Contents]]		[[ASDR Table of Contents]]
−		+	<br>
−	~~__TOC__~~

← Older revision		Revision as of 01:19, 18 February 2009
Line 131:		Line 131:

	Disabling validation exposes this action 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.		Disabling validation exposes this action 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.
		+
		+	===Struts: Validator Without Form Field===
		+	Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
		+
		+	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.
		+
		+	<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.

	==Risk Factors==		==Risk Factors==

@@ Line 111: / Line 111: @@
 An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.
-===Editing Struts: Validator Turned Off===
+===Struts: Validator Turned Off===
 This action form mapping disables the form's validate() method.

← Older revision		Revision as of 01:15, 18 February 2009
Line 110:		Line 110:

	An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.		An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.
		+
		+	===Editing Struts: Validator Turned Off===
		+	This action form mapping disables the form's validate() method.
		+
		+	An action form mapping should never disable validation. Disabling validation disables the Struts Validator as well as any custom validation logic performed by the form.
		+
		+	'''Example'''
		+
		+	An action form mapping that disables validation.
		+
		+	<pre>
		+	<action path="/download"
		+	type="com.website.d2.action.DownloadAction"
		+	name="downloadForm"
		+	scope="request"
		+	input=".download"
		+	validate="false">
		+	</action>
		+	</pre>
		+
		+	Disabling validation exposes this action 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==		==Risk Factors==

← Older revision		Revision as of 01:11, 18 February 2009
Line 101:		Line 101:

	It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.		It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.
		+
		+	===Struts: Unvalidated Action Form===
		+	Every Action Form must have a corresponding validation form.
		+
		+	If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator. If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input.
		+
		+	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.
		+
		+	An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

	==Risk Factors==		==Risk Factors==