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 "Improper Data Validation"
Weilin Zhong (talk | contribs) |
Weilin Zhong (talk | contribs) (Contents provided by Fortify.) |
||
Line 1: | Line 1: | ||
{{Template:Vulnerability}} | {{Template:Vulnerability}} | ||
+ | {{Template:Fortify}} | ||
+ | |||
+ | ==Abstract== | ||
+ | |||
+ | Multiple validation forms with the same name indicate that validation logic is not up-to-date. | ||
==Description== | ==Description== | ||
+ | |||
+ | If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present. | ||
==Examples == | ==Examples == | ||
+ | |||
+ | Two validation forms with the same name. | ||
+ | |||
+ | <pre> | ||
+ | <form-validation> | ||
+ | <formset> | ||
+ | <form name="ProjectForm"> | ||
+ | ... | ||
+ | </form> | ||
+ | <form name="ProjectForm"> | ||
+ | ... | ||
+ | </form> | ||
+ | </formset> | ||
+ | </form-validation> | ||
+ | </pre> | ||
+ | |||
+ | It is critically important that validation logic be maintained and kept in sync with the rest of the application. 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. | ||
==Related Threats== | ==Related Threats== | ||
Line 12: | Line 36: | ||
==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:14, 24 July 2006
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Abstract
Multiple validation forms with the same name indicate that validation logic is not up-to-date.
Description
If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present.
Examples
Two validation forms with the same name.
<form-validation> <formset> <form name="ProjectForm"> ... </form> <form name="ProjectForm"> ... </form> </formset> </form-validation>
It is critically important that validation logic be maintained and kept in sync with the rest of the application. 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.