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
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{Template:Vulnerability}}
+
{{template:CandidateForDeletion}}
{{Template:Fortify}}
 
  
__TOC__
+
#REDIRECT [[Improper Data Validation]]
  
 
[[ASDR Table of Contents]]
 
  
 
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 62:
  
 
__NOTOC__
 
__NOTOC__
 
 
[[Category:OWASP ASDR Project]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Struts]]
 
[[Category:Java]]
 
[[Category:Code Snippet]]
 
[[Category:Implementation]]
 
[[Category:Vulnerability]]
 

Latest revision as of 22:55, 7 April 2009

Template:CandidateForDeletion

#REDIRECT Improper Data Validation


Last revision (mm/dd/yy): 04/7/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