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: Erroneous validate() Method"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
{{Template:Vulnerability}}
+
{{template:CandidateForDeletion}}
{{Template:Fortify}}
+
 
 +
#REDIRECT [[Improper Data Validation]]
 +
 
  
 
__TOC__
 
__TOC__
Line 9: Line 11:
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
  
Line 67: Line 67:
  
 
__NOTOC__
 
__NOTOC__
 
 
[[Category:OWASP ASDR Project]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Struts]]
 
[[Category:Java]]
 
[[Category:Code Snippet]]
 
[[Category:Implementation]]
 
[[Category:Vulnerability]]
 

Revision as of 00:46, 18 February 2009

Template:CandidateForDeletion

#REDIRECT Improper Data Validation



ASDR Table of Contents

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


Description

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

TBD

Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

TBD