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"
Weilin Zhong (talk | contribs) |
Weilin Zhong (talk | contribs) (Contents provided by Fortify.) |
||
| Line 1: | Line 1: | ||
{{Template:Vulnerability}} | {{Template:Vulnerability}} | ||
| + | {{Template:Fortify}} | ||
| + | |||
| + | ==Abstract== | ||
| + | |||
| + | The validator form defines a validate() method but fails to call super.validate(). | ||
==Description== | ==Description== | ||
| + | |||
| + | 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: | ||
| + | |||
| + | <pre> | ||
| + | ValidatorForm | ||
| + | ValidatorActionForm | ||
| + | DynaValidatorForm | ||
| + | DynaValidatorActionForm | ||
| + | </pre> | ||
| + | |||
| + | 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. | ||
==Examples == | ==Examples == | ||
| Line 12: | Line 30: | ||
==Related Countermeasures== | ==Related Countermeasures== | ||
| + | |||
| + | [[:Category:Input Validation]] | ||
==Categories== | ==Categories== | ||
| − | |||
| − | |||
[[Category:Input Validation Vulnerability]] | [[Category:Input Validation Vulnerability]] | ||
| − | |||
[[Category:Struts]] | [[Category:Struts]] | ||
| + | [[Category:Java]] | ||
| + | [[Category:Code Snippet]] | ||
| + | [[Category:Implementation]] | ||
Revision as of 18:15, 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
Abstract
The validator form defines a validate() method but fails to call super.validate().
Description
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.
