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: Form Field Without Validator"
Weilin Zhong (talk | contribs) m (→Categories) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | Every field in a form should be validated in the corresponding validation form. | ||
Omitting validation for even a single input field may allow attackers the leeway they need. | Omitting validation for even a single input field may allow attackers the leeway they need. | ||
| Line 14: | Line 22: | ||
Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. '''It is critical that unused fields be validated too.''' Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form. | Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. '''It is critical that unused fields be validated too.''' Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form. | ||
| − | |||
| − | ==Related | + | ==Risk Factors== |
| + | |||
| + | TBD | ||
| + | |||
| + | ==Examples== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | ==Related [[Attacks]]== | ||
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[:Category:Input Validation]] | ||
| + | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| − | + | TBD | |
| − | |||
| − | |||
| − | + | __NOTOC__ | |
| − | |||
| + | [[Category:OWASP ASDR Project]] | ||
[[Category:Input Validation Vulnerability]] | [[Category:Input Validation Vulnerability]] | ||
[[Category:Struts]] | [[Category:Struts]] | ||
[[Category:Java]] | [[Category:Java]] | ||
[[Category:Implementation]] | [[Category:Implementation]] | ||
Revision as of 00:07, 1 October 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 10/1/2008
Vulnerabilities Table of Contents
Description
Every field in a form should be validated in the corresponding validation form.
Omitting validation for even a single input field may allow attackers the leeway they need.
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.
Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form.
Risk Factors
TBD
Examples
TBD
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD
