CWE - CWE-105: Struts: Form Field Without Validator (4.9)

Weakness ID: 105

Abstraction: Variant
Structure: Simple

View customized information:

Description

The application has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.

Extended Description

Omitting validation for even a single input field may give attackers the leeway they need to compromise the application. 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.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1173	Improper Use of Validation Framework

Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation	Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings.

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Java (Undetermined Prevalence)

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Integrity	Technical Impact: Unexpected State
Integrity	Technical Impact: Bypass Protection Mechanism 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.

Demonstrative Examples

Example 1

In the following example the Java class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for an online business site. The user will enter registration data and, through the Struts framework, the RegistrationForm bean will maintain the user data in the form fields using the private member variables. The RegistrationForm class uses the Struts validation capability by extending the ValidatorForm class and including the validation for the form fields within the validator XML file, validator.xml.

(result)

public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {

// private variables for registration form
private String name;
private String address;
private String city;
private String state;
private String zipcode;
private String phone;
private String email;

public RegistrationForm() {

super();

}

// getter and setter methods for private variables
...

}

The validator XML file, validator.xml, provides the validation for the form fields of the RegistrationForm.

(bad code)

Example Language: XML

<form-validation>

</field>
<field property="address" depends="required">

</field>
<field property="city" depends="required">

</field>
<field property="state" depends="required,mask">

<var-name>mask</var-name>
<var-value>[a-zA-Z]{2}</var-value>

</var>

</field>
<field property="zipcode" depends="required,mask">

<var-name>mask</var-name>
<var-value>\d{5}</var-value>

</var>

</field>

</form>

</formset>

</form-validation>

However, in the previous example the validator XML file, validator.xml, does not provide validators for all of the form fields in the RegistrationForm. Validator forms are only provided for the first five of the seven form fields. The validator XML file should contain validator forms for all of the form fields for a Struts ActionForm bean. The following validator.xml file for the RegistrationForm class contains validator forms for all of the form fields.

(good code)

Example Language: XML

<form-validation>

</field>
<field property="address" depends="required">

</field>
<field property="city" depends="required">

</field>
<field property="state" depends="required,mask">

<var-name>mask</var-name>
<var-value>[a-zA-Z]{2}</var-value>

</var>

</field>
<field property="zipcode" depends="required,mask">

<var-name>mask</var-name>
<var-value>\d{5}</var-value>

</var>

</field>
<field property="phone" depends="required,mask">

<var-name>mask</var-name>
<var-value>^([0-9]{3})(-)([0-9]{4}|[0-9]{4})$</var-value>

</var>

</field>
<field property="email" depends="required,email">

</field>

</form>

</formset>

</form-validation>

Potential Mitigations

Phase: Implementation

Validate all form fields. If a field is unused, it is still important to constrain it so that it is empty or undefined.

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	990	SFP Secondary Cluster: Tainted Input to Command

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Struts: Form Field Without Validator
Software Fault Patterns	SFP24		Tainted input to command

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	7 Pernicious Kingdoms
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Common_Consequences, Description, Modes_of_Introduction, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Causal_Nature, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Potential_Mitigations


	Site Map \| Terms of Use \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2023, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-105: Struts: Form Field Without Validator