Java Developer Tools

Audit - Rules - Struts

Description
This group contains audit rules that look for code that violates the best practices specified for programs using the Struts framework.

Rules:

Details

Action Field Revalidated

Summary
Only one <field-validator> should be declared for one action field.

Description
This audit rule violates <field-validator> declarations that repeat more than once for one action field.

Security Implications
When action field validator is declared more than once for one action field this could lead to an unexpected behavior or failure to validate the user input properly that could possibly allow an attacker to perform some kind of remote attack on a system.

Example
The following declaration in MyAction-validation.xml declares validator for the field name twice and would thus be marked as violation:it results in an found bind:

    <field name="name">
        <field-validator type="required">
            <message>Name is required.</message>
        </field-validator>
        <field-validator type="required">
            <message>Please enter your name.</message>
        </field-validator>
    </field>

Action Revalidated

Summary
Only one ActionName-validation.xml file should be declared for one action.

Description
This audit rule violates ActionName-validation.xml declarations that are found more than once in the project.

Security Implications
When an action validator is declared more than once for one action, this could lead to an unexpected behavior or failure to validate the user input properly which could possibly allow an attacker to perform some kind of remote attack on a system.

Example
A validation file MyAction-validation.xml for MyAction that is present in more than one place in the project will be marked as a violation.

Avoid Fields in Action Classes

Summary
Fields must not be used in action classes.

Description
This audit rule looks for fields in action classes. It will allow fields that are marked as "final", but other fields, whether instance or static, are flagged.

Example
In the class below, the field "count" would be flagged:

    public class MyAction extends Action {
        private int count;
        ...
    }

Business Logic in ActionForm

Summary
ActionForms should not contain any business logic.

Description
This audit rule looks for subclasses of ActionForm that contain business logic. ActionForms should only be used to keep form data passed between the view and the controller. An ActionForm has business logic if it contains any methods other than getters, setters and a few other specific methods (validate, reset, toSession, and fromSession). Business logic should be moved into the model.

Example
In the following class, the method generatePassword would be flagged as business logic that needs to be moved.

    public class UserFormBean extends ActionForm {
        private String email = "Missing address";
        private String password = "Missing password";

        public String getEmail() {
            return(email);
        }

            public void setEmail(String email) {
            this.email = email;
        }

        public String getPassword() {
            return(password);
        }

        public void setPassword(String password) {
            this.password = password;
        }

        public void generatePassword() {
            Random r = new Random(System.currentTimeMillis());
            int len = 6 + r.nextInt() % 12;
            byte[] pass = new byte[len];
            for(int i = 0; i < len; i++) {
                ...
            }
            ...
        }
    }

Class Should Define Validate Method

Summary
If a class extends org.apache.struts.action.ActionForm, it must define a validate method.

Description
This audit rule looks for subclasses of ActionForm that do not implement a validate method. The validate method is the standard mechanism for a Struts framework to validate fields.

Security Implications
Fields that are not validated are security problem number one for web applications. Failing to validate fields can lead to many security vulnerabilities such as SQL injections and Cross-site scripting.

Example
The following class would be flagged as a violation because the class in this example doesn't define validate method:

    class MyClass extends ActionForm
    {
            ...
    }
    

Class Should Have Final Static Fields

Summary
If a class extends org.apache.struts.action.ActionForm, it must not contains non-final static fields.

Description
This audit rule looks for subclasses of ActionForm that define non-final static fields.

Security Implications
Non-final static fields can be changed by different instances of the form at the same time (on different threads), or between the time of change and the time of use. This fact can provide an opportunity for malicious code to make unsafe changes even if the field is private.

Example
The following field would be flagged as a violation because it is static but is not final:

    class MyClass extends ActionForm
    {
            public static String testStr = "Value";
    }

Class Should Have Private Fields

Summary
If a class extends org.apache.struts.action.ActionForm, it must contain only private fields.

Description
This audit rule looks for subclasses of ActionForm that define non-private fields that are accessed by getters and setters. The setter method should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided.

Security Implications
Non-private fields can be accessed in a way that avoids validation and creates an invalid state for the Form object. This can be used by malicious code to create unexpected and unintended behavior.

Example
The following field would be flagged as a violation because it is not private:

    class MyClass extends ActionForm
    {
            public static testStr = "Value";
    }
    

Class Should Validate All Fields

Summary
If a class extends org.apache.struts.action.ActionForm, it should validate all of the fields it declares.

Description
This audit rule looks for subclasses of ActionForm in which the validate method does not validate all of the fields defined by the class.

Security Implications
Unvalidated fields is the number one security issue for web-applications. Unvalidated fields can lead to many security vulnerabilities such as SQL Injections and Cross Site scripting.

Example
The following class would be flagged as a violation because the field count is not validated by validate method.

    class MyClass extends ActionForm
    {
        private testStr = "Value";
        private int count;

        public ActionErrors validate(ActionMapping map,
                        ServletRequest req)        {
            ActionErrors err ActionErroes();
            if (testStr == null) {
                err.add(ActionErrors.GLOBAL_MESSAGE,
                                new ActionMessage("testStr is null"));
            }
            return super(map, req);
        }
    }
    

Create Global Forward

Summary
Use global forwards to avoid redundant forwards.

Description
This audit rule looks for ActionForwarder instances that refer to the same page. If there are several actions doing redirection to the same page, it is better to create and use a global redirect.

Example
Replace code like the following:

    public class Action1 extends Action {
        ...
        public ActionForward execute(...) throws Exception {
        ...
            ActionForward forward = new ActionForward("/jsp/example.jsp");
            return forward;
        }
    }

and

    public class Action2 extends Action {
        ...
        public ActionForward execute(...) throws Exception {
            ...
            ActionForward forward = new ActionForward("/jsp/example.jsp");
            return forward;
        }
    }

with code like the following:

    public class Action1 extends Action {
        ...
        public ActionForward execute(...) throws Exception {
            ...
            return mapping.findForward("globalForwardName");
        }
    }

and

    public class Action2 extends Action {
        ...
        public ActionForward execute(...) throws Exception {
            ...
            return mapping.findForward("globalForwardName");
        }
    }

Of course, you must also define your global forward in the configuration file, something like the following:

    <global-forwards>
        <forward name="globalForwardName" path="/jsp/example.jsp" />
    </global-forwards>

Declare Accessors for All ActionForm Fields

Summary
Declare public accessors for all ActionForm fields.

Description
This audit rule looks for fields declared in ActionForm classes for which either the getter or setter method is not implemented. If accessor methods are not implemented, using this tag on a JSP page such as

    <html:text property="fieldName">

may cause an error.

Example
The following class would be flagged because it does not implement a setter method for the "username" field.

    public class LoginForm extends ActionForm {
        private String password = null;
        private String username = null;

        public String getUsername() {
            return (this.username);
        }

        public String getPassword() {
            return (this.password);
        }

        public void setPassword(String password) {
            this.password = password;
        }
    }

Don't Create Unused Error

Summary
Don't create ActionErrors in validate() methods of ActionForm until an error is discovered.

Description
This audit rule finds all created ActionError and ActionMessage instances and checks to see whether they are added (with method add) to the returned ActionErrors instance.

Example
In the following method, the error assigned to the local variable named "error" would be flagged because it not added to the "errors" collection:

    public ActionErrors validate(ActionMapping mapping,
            HttpServletRequest request) {
        ActionError error = new ActionError(null);
        ActionMessage message;
        message = new ActionMessage(null);
        ActionErrors errors = new ActionErrors();
        errors.add(ActionErrors.GLOBAL_ERROR, new ActionError("error.error"));
        errors.add(ActionErrors.GLOBAL_ERROR, message);
        return errors;
    }

Duplicate Validation Form

Summary
Multiple validation forms with the same name indicate that the 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.

Example
If your validaton.xml file contains

    <form-validation>
        <formset>
            <form name="ProjectForm">
            ...
            </form>
            <form name="ProjectForm">
            ...
            </form>
        </formset>
    </form-validation>

then the second entry of form name="ProjectForm" would be flagged.

Form Does Not Extend Validator Class

Summary
Struts forms that are defined to use validation should extend a validator class.

Description
In order to use the Struts Validator, a form must extend one of the following classes:

    org.apache.struts.validator.DynaValidatorActionForm
    org.apache.struts.validator.DynaValidatorForm
    org.apache.struts.validator.ValidatorActionForm
    org.apache.struts.validator.ValidatorForm

You must extend one of these classes because the Struts Validator ties in to your application by implementing the validate() method in these classes.Forms derived from the following classes cannot use the Struts Validator:

    org.apache.struts.action.ActionForm
    org.apache.struts.action.DynaActionForm

Example
If the struts-config.xml file contained the following tag and the class example.NotValidatorForm does not extends one of the validator classes listed above, the bean notValidatorForm would be flagged:

    <form-bean name="notValidatorForm" type="example.NotValidatorForm"/>

Incomplete reset()

Summary
Reset each member variable in the reset() method.

Description
If the reset() method is implemented, this audit rule checks to make sure that each member variable is reset.

Example
The reset method below would be flagged because the username field is not reset.

    public class LoginForm extends ActionForm {
        private String password = null;
        private String username = null;

        ...

        public void reset(ActionMapping mapping,
                    HttpServletRequest request) {
            this.password = null;
        }
    }

Invalid Form Bean Class

Summary
Classes used as form beans must subclass ActionForm.

Description
All classes declared to be a form bean using the form-bean tag should be real form classes (be subclasses of ActionForm).

Example
If the class com.instantiations.struts.example.actionforms.LoginForm did not extended the class ActionFrom, the following line would be flagged:

    <form-bean
        name="loginForm"
        type="com.instantiations.struts.example.actionforms.LoginForm"/>

Notes

You can also use one of the following Struts forms:

    org.apache.struts.validator.ValidatorForm
    org.apache.struts.mock.MockFormBean
    org.apache.struts.action.DynaActionForm
    org.apache.struts.validator.DynaValidatorForm
    org.apache.struts.validator.DynaValidatorActionForm
    org.apache.struts.validator.BeanValidatorForm
    org.apache.struts.validator.LazyValidatorForm
    org.apache.struts.validator.ValidatorActionForm

Invoke super.validate() in validate()

Summary
Always call super.validate() in your validate methods in ActionForm and check is super.validate() return null or not.

Description
The validate() method should be implementated to invoke super.validate(), assigning the result to a local variable so that it can be compared with null, similar to the following example:

    public ActionErrors validate(ActionMapping mapping,
                        HttpServletRequest request) {
        ActionErrors errors = super.validate(mapping, request);
        if (errors == null){
            errors = new ActionErrors();
        }
        // Code to add additional errors.
        return errors;
    }

Example
The following method would be flagged because it does not invoke super.validate():

    public class MyActionForm extends ActionForm {
        public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
            ActionErrors errors = new ActionErrors();
            errors.add(ActionErrors.GLOBAL_ERROR, new ActionError("error.error"));

            ...

            return errors;
        }
    }

Missing Class in web.xml

Summary
A class referenced in a web.xml file is not defined.

Description
This audit rule checks the values of those attributes in a web.xml file whose values are supposed to be the fully qualified name of a class to ensure that the classes are defined.

Example
In the following entry

    <controller className="your class here" .../>

The value of the "className" attribute would be flagged.

Missing reset() Method

Summary
Struts ActionForm subclasses should implement the reset() method.

Description
This audit rule finds ActionForm subclasses that do not implement the reset() method.

Security Implications
If some fields are not reset, they can have old values which can be used by an attacker.

Example
The following class declaration would be flagged as a violation because it does not declare a reset() method:

    public class SomeForm extends ActionForm { }

Missing Validator Name

Summary
All validators used in validation logic should be declared in validators.xml configuration file.

Description
This audit rule finds and violates the usages of validators whose type is not declared in validators.xml.

Security Implications
The absence of a declaration of a validator used is a sign of a faulty approach to secure validation all other the application. Validation logic should be kept up to date.

Example
The following customBarFieldValidation validator usage whould be marked as violation if the corresponding validator is not declared in validators.xml configuration file:

    <validators>
        <field name="bar">
                <field-validator type="customBarFieldValidation">
                        <message>You must enter a value for bar.</message>
                </field-validator>
        </field>
    </validators>

No Action For Validation

Summary
Abandoned validation file is a sign that validation of the actions is not properly handled.

Description
A validation file without a corresponding action could be a result of an action renaming, when developer forgot to rename a validation file.

Security Implications
It indicates problems in the validation of the actions, that should be treated.

Example
When file AddItem-validation.xml is found with no corresponding action in struts.xml, the violation is created. The proper action declaration in this case would look like this:

    <struts>
        ...
        <package name="sample" namespace="/sample" extends="struts-default">
            <action name="AddItem" class="my.sample.AddItemAction">
                <result>/pages/AddItem.jsp</result>
            </action>
        </package>
        ...
    </struts>

No Such Field For Validation

Summary
Abandoned field validation is a sign that validation of the actions is not properly handled.

Description
A field validation declared without a corresponding field in the action class could be a result of a field being renamed, when the developer forgot to replace the field name in a validation file.

Security Implications
It indicates problems in the validation of the actions, that should be treated.

Example
Let there be a Struts form class, PostForm, that declares two fields, title and message. The following entry in the file PostForm-validation.xml will lead to a violation because it validates a non-existent field:

    <field name="name">
        <field-validator type="requiredstring">
            <message>You must enter a name</message>
        </field-validator>
    </field>

Same Validator Name

Summary
Duplicating validator names cause errors in validation process.

Description
This audit rule violates declarations of a validators with the same name attribute.

Security Implications
From two validators with the same name only one will be executed. Duplicating validator names is usually a sign that validation in the application is out of order and should be fixed. Failing in doing so will allow the attacker to inject some kind of invalid data into application.

Example
The following validators.xml configuration contains two declared validators with the same name; these declarations would be violated:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator Config 1.0//EN" "http://www.opensymphony.com/xwork/xwork-validator-config-1.0.dtd">
    <validators>
        <validator name="custom" class="org.some.validation.old.CustomValidator1"/>
        <validator name="custom" class="org.some.validation.new.CustomValidator2"/>
    </validators>

Session Must Be Synchronized

Summary
References to the session must be synchronized.

Description
This audit rule looks for references to the session object that are not synchronized on the session. Because the controller servlet creates only one instance of your Action class and uses this one instance to service all requests, you need to write thread-safe Action classes. In particular, all references to the session object should be synchronized.

Example
The following method would be flagged because of the references to session:

    public ActionForward execute(ActionMapping mapping, ActionForm inForm,
            HttpServletRequest request, HttpServletResponse response) throws Exception {
        HttpSession session = request.getSession();
        if (session != null && session.getAttribute("user") != null) {
            session.setAttribute("user", (String) request.getParameter("username"));
            return mapping.findForward("success");
        }
        return mapping.findForward("fail");
    }

It should be replaced by something similar to the following:

    public ActionForward execute(ActionMapping mapping, ActionForm inForm,
            HttpServletRequest request, HttpServletResponse response) throws Exception {
        HttpSession session = request.getSession();
        synchronized (session) {
            if (session != null && session.getAttribute("user") != null) {
                session.setAttribute("user", (String) request.getParameter("username"));
                return mapping.findForward("success");
            }
            return mapping.findForward("fail");
        }
    }

Session-scope Form Needs reset()

Summary
The reset() method in an ActionForm should be implemented if the form has session scope (it's not used for request scope).

Description
This audit rule looks for classes that implement a form bean used by a session-scoped action and checks ro ensure that those classes implement a reset method.

Example
If the configuration file contains following entries:

    <action path="/viewsignin"
        type="com.instantiations.struts.example.actions.LoginAction"
        scope="session"
        name="loginForm"
        validate="false"
        input="/index.jsp"
        parameter="/signin.jsp">

and

    <form-bean name="loginForm"
            type="com.instantiations.struts.example.actionforms.LoginForm"/>

then the class LoginForm would be flagged if it does not define a reset method.

Struts Validator Not in Use

Summary
Use the Struts validator to prevent vulnerabilities that result from unchecked input.

Description
Unchecked input is the leading cause of vulnerabilities in J2EE applications. To prevent such attacks, use the Struts validator to check all program input before it is processed by the application. To use the Struts validator you should configure it in struts-config.xml:

    <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
        ...
    </plug-in>

Example
The tag <struts-config> would be flagged if it does not contain a ValidatorPlugIn declaration:

    <struts-config>
        ...
    <struts-config>

Undefined Message Key

Summary
Message keys must be defined in the resource file.

Description
This audit rule looks for uses of message keys that are not defined in the resource file. All messages created in the Action and ActionForm classes should be declared in the special resource file, which can be found with the Struts configuration file.

Example
In the following code, the name of the message key would be flagged if the key "messages.invaliduser" did not exist in the resource file.

    public ActionForward execute(ActionMapping mapping, ActionForm inForm,
            HttpServletRequest request, HttpServletResponse response) throws Exception {
        ...
        {
            ActionMessages messages = new ActionMessages();
            messages.add(ActionMessages.GLOBAL_MESSAGE,
                new ActionMessage("messages.invaliduser"));
            saveErrors(request, messages);
            return mapping.findForward("fail");
        }
        ...
    }

Unused Validation Form

Summary
An unused validation form indicates that validation logic is not up-to-date.

Description
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.

Example
If the struts-config.xml file contains:

    <form-beans>
        <form-bean name="login" type="example.LoginForm"/>
        <form-bean name="validateForm" type="example.ValidatedForm"/>
    </form-beans>

and the validation.xml file contains

    <form-validation>
        <formset>
            <form name="login"/>
            <form name="validatedForm"/>
        </formset>
    </form-validation>

the entry for "validatedForm" would be flagged in the validation.xml file because it is not defined in struts-config.xml (note the subtle name difference).

Unvalidated Action Field

Summary
All fields of a Struts2 action should be validated even if some of them are unused.

Description
In situations when one Struts2 action class is used in several forms and each form uses a subset of the classes fields it is a common mistake to validate only those fields which are used in a given form.

Security Implications
This may allow an attacker to inject unvalidated input into your application. Thus, all fields of a form should be validated even if some of them are unused.

Example
Let there be a Struts2 action class, QuizAction, that declares three fields, name, age and answer. The following entry in the QuizAction-validation.xml will lead to a violation because it validates only two of them:

    <validators>
        <field name="name">
            <field-validator type="requiredstring">
                <message>You must enter a name</message>
            </field-validator>
        </field>
        <field name="age">
            <field-validator type="int">
                <param name="min">13</param>
                <param name="max">19</param>
                <message>Only people ages 13 to 19 may take this quiz</message>
            </field-validator>
        </field>
    </validators>

Unvalidated Action Form

Summary
Every action form must have a corresponding validation form.

Description
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.

Example
If the validation.xml file contains

    <form-validation>
        <formset>
            <form name="login"/>
            <form name="unvalidatedForm"/>
        </formset>
    </form-validation>

and struts-config.xml file contains:

    <form-beans>
        <form-bean name="login" type="example.LoginForm"/>
        <form-bean name="validatedForm" type="example.ValidatedForm"/>
    </form-beans>

then the action form validatedForm would be flagged because it's not referenced in validation.xml.

Unvalidated Action Form Field

Summary
All fields of a Struts action form should be validated even if some of them are unused.

Description
In situations when one Struts action form class is used in several forms and each form uses a subset of the classes fields it is a common mistake to validate only those fields which are used in a given form.

Security Implications
This may allow an attacker to inject unvalidated input into your application. Thus, all fields of a form should be validated even if some of them are unused.

Example
Let there be a Struts form class, QuizAction, that declares three fields, name, age and answer. The following entry in the validation.xml will lead to a violation because it validates only two of them:

    <form name="quizForm">
        <field property="name" depends="required">
            <arg key="quizForm.name"/>
        </field>
        <field property="age" depends="required">
            <arg key="quizForm.age"/>
        </field>
    </form>

Use Action Interface

Summary
Use the Action interface rather than the Action abstract class.

Description
This audit rule looks for actions that subclass the abstract class org.apache.struts.action.Action. They should subclass the interface org.apache.struts2.Action instead.

Example
Replace this code

    public class NewAction extends Action {
        public org.apache.struts.action.ActionForward execute(
        org.apache.struts.action.ActionMapping mapping,
        org.apache.struts.action.ActionForm form,
        javax.servlet.http.HttpServletRequest request,
        javax.servlet.http.HttpServletResponse response)
            throws java.lang.Exception
        {
            ...
            return mapping.findForward("forward_name");
        }
    }

with

    public class NewAction implements Action {
        public String execute() {
            ...
            return "forward_name";
        }
    }

Use Existing Global Forwards

Summary
Use the global forwards defined in the configuration file.

Description
This audit rule looks for ActionForwarder instances that refer to a page defined in configuration file. Such instances should return a global redirect to the referenced page in order to make it easier to modify the redirect.

Example
If the struts-config.xml file includes

    <global-forwards>
        <forward name="globalForwardName" path="/jsp/example.jsp" />
    </global-forwards>

then the following execute method would be flagged:

    public ActionForward execute(...)
             throws Exception {
        ...
        ActionForward forward = new ActionForward("/jsp/example.jsp");
        return forward;
    }

Use ForwardAction Where Possible

Summary
Do not create action classes that can be replaced with ForwardAction.

Description
This audit rule looks for actions that can be replaced with ForwardAction. Actions should be implemented using standard classes when possible in order to increase the flexability of the system.

Example
The following class would be flagged because it could be replaced by an instance of ForwardAction.

    public class MyAction extends Action {
        public ActionForward execute(ActionMapping mapping,
                    ActionForm form,
                    HttpServletRequest request,
                    HttpServletResponse response)
                throws Exception {
            return(mapping.findForward("some_forward_action_name"));
        }
    }

Use html:messages Instead of html:errors

Summary
Use html:messages instead of html:errors.

Description
This audit rule looks for uses of the html:errors tag within JSP files. When error messages need to be displayed to the end user, the html:messages tag should be used instead because it gets the markup language out of the resource bundle.

Example
The following JSP tag would be flagged:

    <html:errors ... >

Use Interceptor to Track Duplicate Submits

Summary
Don't use any token code in an Action class at all. The interceptors are designed to do all the work.

Description
This audit rule looks for calls to saveToken(), resetToken() and isTokenValid(). Advises to replace them with a corresponding interceptor.

Example
The following method would be flagged because of the invocation of the saveToken method:

    public ActionForward execute(...) throws Exception {
        ...
        // Create token.
        saveToken(request);
        return mapping.findForward("success");
    }

Similarly, the following method would be flagged because of the invocations of the isValidToken and resetToken methods:

    public ActionForward execute(...) throws Exception {
        // Validate token for duplication submission.
        if (!isTokenValid(request)) {
            return mapping.findForward("duplicate");
        } else {
            ...
        }
        // Reset token after transaction success.
        resetToken(request);
        return mapping.findForward("success");
    }

Use StrutsTestCase for Unit Testing

Summary
Use StrutsTestCase instead of TestCase for unit-testing Struts classes.

Description
This audit rule looks for subcasses of TestCase that include methods to test Struts-related classes. They should subclass StrutsTestCase in order to make use of the additional functionality defined by it.

Example
The following class would be flagged because it extends TestCase even though it is clearly testing a Struts class.

    public class LoginActionTest extends TestCase {
        public void testExecute() {
            LoginAction loginAction = new LoginAction();
            assertEquals(...);
            ...
        }
    }

Use SuccessAction Where Possible

Summary
Do not create action classes that can be replaced with SuccessAction.

Description
This audit rule looks for actions that can be replaced with SuccessAction. Actions should be implemented using standard classes when possible in order to increase the flexability of the system.

Example
The following class would be flagged because it could be replaced by an instance of SuccessAction.

    public class MyAction extends Action {
        public ActionForward execute(ActionMapping mapping,
                    ActionForm form,
                    HttpServletRequest request,
                    HttpServletResponse response)
                throws Exception {
            return mapping.findForward("success");
        }
    }

Use Valid Type for Form-property

Summary
All form-property tags in the Struts configuration file should have a valid type property.

Description
This audit rule looks for form-property tags in the Struts configuration file that have an invalid type property. The type property should have one of the following values:
* java.math.BigDecimal
* java.math.BigInteger
* boolean and java.lang.Boolean
* byte and java.lang.Byte
* char and java.lang.Character
* java.lang.Class
* double and java.lang.Double
* float and java.lang.Float
* int and java.lang.Integer
* long and java.lang.Long
* short and java.lang.Short
* java.lang.String
* java.sql.Date
* java.sql.Time
* java.sql.Timestamp

You may also specify Arrays of these types (e.g. String[]) as well as concrete implementations of the Map interface, such as java.util.HashMap, or a List implementation, such as java.util.ArrayList.

Example:
The properties "page" and "data" would be flagged because they are using invalid types.

    <form-bean name="checkoutForm" type="org.apache.struts.validator.DynaValidatorForm">
        <form-property name="address" type="java.lang.String"/>
        <form-property name="age" type="java.lang.Integer"/>
        <form-property name="page" type="java.lang.StringBuffer"/>
        <form-property name="data" type="java.lang.Object"/>
    </form-bean>

Validation Not Enabled

Summary
Validation plug-in is disabled by default and should be explicitly enabled in Struts configuration.

Description
This rule violates struts-config.xml configuration file that does not explicitly specify Validation framework enabled.

Security Implications
Unvalidated input can be used by an attacker to perform all kinds of remote attacks.

Example
The following code declares the usage of Struts validation framework. If struts-config.xml configuration file does not contain this code, it will be violated:

    <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
        <set-property property="pathnames" value="/technology/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
    </plug-in>

Validator Configuration File Does Not Exist

Summary
XML files referenced as validator configuration files in the struts-config.xml file should exist.

Description
The Struts configuration file may specify two validator configuration files. This audit rule checks to ensure that every declared validator configuration file exists.

Example
Given the following content in the struts-config.xml file:

    <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
        <set-property property="pathnames" value="/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
    </plug-in>

The appropriate value would be flagged, if either validator-rules.xml or validation.xml does not exist.

Validator Disabled

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.