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: Unvalidated Action Form"
Weilin Zhong (talk | contribs) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{ | + | {{template:CandidateForDeletion}} |
| + | |||
| + | #REDIRECT [[Improper Data Validation]] | ||
| + | |||
| + | |||
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
==Description== | ==Description== | ||
| − | ==Examples == | + | 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== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | ==Examples== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | ==Related [[Attacks]]== | ||
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[:Category:Input Validation]] | ||
| − | |||
| − | ==Related | + | ==Related [[Technical Impacts]]== |
| − | + | * [[Technical Impact 1]] | |
| + | * [[Technical Impact 2]] | ||
| − | |||
| − | == | + | ==References== |
| − | + | TBD | |
| − | |||
| − | + | __NOTOC__ | |
Latest revision as of 23:02, 7 April 2009
#REDIRECT Improper Data Validation
Last revision (mm/dd/yy): 04/7/2009
Description
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
TBD
Examples
TBD
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD
