ABSTRACT

Every field in a form should be validated in the corresponding validation form.

EXPLANATION

Omitting validation for even a single input field can 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 could allow attackers to bypass the validation checks that are performed for other uses of the form.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input

[2] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A6 Security Misconfiguration

[3] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I

[4] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 105

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1

[7] Standards Mapping - FIPS200 - (FISMA) SI

[8] T. Husted et al. Struts in Action: Building Web Applications with the Leading Java Framework Manning Publications

[9] The Struts project The Apache Foundation