Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

Struts 2 introduced a feature called "Dynamic Method Invocation" which allow an Action to expose methods other than execute(). The ! (bang) character or the method: prefix can be used in the Action URL to invoke any public method in the Action if "Dynamic Method Invocation" is enabled. Developers that are not aware of this feature can inadvertently expose internal business logic to attackers.

As an example, if the Action contains a public method called getUserPassword() that takes no arguments and fails to disable the "Dynamic Method Invocation" feature, an attacker will be able to take advantage of this visiting the following URL: http://server/app/recoverpassword!getPassword.action

Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

One or more Action Fields do not have a corresponding validation definition. Each field should have an explicit validation routine referenced in ActionClass-validation.xml.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the lack of a validator definition.

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.

More than one field validator definition with the same name exist in ActionClass-validation.xml. Duplicate validation definitions with the same name may result in unexpected behavior.

Example 1: The following entry shows two duplicate field validator definitions.

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

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.

More than one ActionClass-validation.xml file was discovered for this Struts2 Action definition. For each Struts2 Action defined in the form of ActionClass, Struts2 searches for a corresponding ActionClass-validation.xml for the necessary validation constraints. Having multiple validation definitions for one Action included in the deployment may result in unexpected behavior.

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.

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.

More than one validator definition was discovered in validators.xml. Multiple validation definitions with the same name may result in unexpected behavior.

If two validation classes are defined with 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.

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.

Struts2 requires that custom validators be defined in validators.xml before being used in a Action validator definition. Missing validator definitions are an indication that validation is not up to date.

Example 1: The following Action validator was not defined in validators.xml.

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

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.

Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, and SQL injection. 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.

To prevent such attacks, use the Struts Validation framework to check all program input before it is processed by the application. Use Fortify Static Code Analyzer to ensure that there are no holes in your configuration of the Struts Validator.

Example uses of the validator include checking to ensure that:

- Phone number fields contain only valid characters in phone numbers

- Boolean values are only "T" or "F"

- Free-form strings are of a reasonable length and composition

A Struts2 Validation file was discovered without a matching Struts2 Action. For each ActionClass, Struts2 searches for a corresponding ActionClass-validation.xml for the necessary validation constraints. In this case, a validation file in the form of ActionClass-validation.xml was found, but ActionClass does not match an Action defined in the Struts2 configuration file.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.

A Struts2 validator definition refers to an action field that does not exist.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an orphaned validator definition.

Duplicate form-bean names serve no purpose since only the last entry will be registered when the same name is used in multiple <form-bean> tags.

Example 1: The following configuration has two form-bean entries with the same name.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts uses the path attribute to locate the resource necessary to handle a request. Since the path is a module-relative location, it is an error if it does not begin with a "/" character.

Example 1: The following configuration contains an empty path.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

Example 2: The following configuration uses a path that does not start with a "/" character.

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

The struts specification requires an input attribute whenever a named action returns validation errors[2]. The input attribute specifies the page used to display error messages when validation errors occur.
Example 1: The following configuration defines a named validating action, but does not specify an input attribute.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

The <exception> tag requires that an exception type be defined. A missing or empty type attribute is indicative of either a superfluous exception handler or an accidental omission. If a developer intended to handle an exception, but forgot to define the exception type, then the application might leak sensitive information about the system.
Example 1: The following configuration omits the type from the <exception> tag.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

Struts uses form-bean entries to map HTML forms to actions. If the name attribute in an <action> tag does not correspond with the name of a form-bean, the action cannot be mapped and indicates either a superfluous definition or a typographical error.

Example 1: The following configuration does not contain a mapping for bean2.

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

Struts uses the form-bean name to map HTML forms to actions. If a form-bean does not have a name, it cannot be mapped to an action and indicates either a superfluous definition or an accidentally omitted bean.
Here is a proper form-bean example:
Example 1: The following form-bean has an empty name attribute.

<form-beans>
  <form-bean name="" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts uses form-bean entries to map HTML forms to actions. If a form-bean does not have a type, it cannot be mapped to an action.
Example 1: The following form-bean has an empty type attribute.

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts requires <form-property> tags to include a type attribute. Struts will throw an exception when processing a form that defines a form-property with no type.

Example 1: The following configuration omits a type for the name property.

<form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
  <form-property name="name" />
  <form-property name="password" type="java.lang.String" />
</form-bean>