You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Security tips

The Apache Struts 2 doesn't provide any security mechanism - it is just a pure web framework. Below are few tips you should consider during application development with the Apache Struts 2.

Restrict access to the Config Browser

Config Browser Plugin exposes internal configuration and should be used only during development phase. If you must use it on production site, we strictly recommend restricting access to it - you can use  Basic Authentication or any other security mechanism (e.g. Apache Shiro)

Don't mix different access levels in the same namespace

Very often access to different resources is controlled based on URL patterns, see snippet below. Because of that you cannot mix actions with different security levels in the same namespace. Always group actions in one namespace by security level.

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>admin</web-resource-name>
            <url-pattern>/secure/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Internal security mechanism

The Apache Struts 2 contains internal security manager which blocks access to particular classes and Java packages - it's a OGNL-wide mechanism which means it affects any aspect of the framework ie. incoming parameters, expressions used in JSPs, etc.

The defaults are as follow:

    <constant name="struts.excludedClasses"
              value="
                java.lang.Object,
                java.lang.Runtime,
                java.lang.System,
                java.lang.Class,
                java.lang.ClassLoader,
                java.lang.Shutdown,
                ognl.OgnlContext,
                ognl.MemberAccess,
                ognl.ClassResolver,
                ognl.TypeConverter,
                com.opensymphony.xwork2.ActionContext" />
    <!-- this must be valid regex, each '.' in package name must be escaped! -->
    <constant name="struts.excludedPackageNamePatterns" value="^java\.lang\..*,^ognl.*,^javax.*" />

Any expression or target which evaluates to one of these will be blocked and you see a WARN in logs:

[WARNING] Target class [class example.MyBean] or declaring class of member type [public example.MyBean()] are excluded!

In that case new MyBean() was used to create a new instance of class (inside JSP) - it's blocked because target of such expression is evaluated to java.lang.Class

It is possible to redefine the above constants in struts.xml but try to avoid this and rather change design of your application!

Accessing static methods

In case you still use static methods in expressions (setting struts.ognl.allowStaticMethodAccess to true) please be aware that this won't work anymore as internal security mechanism consider this as access to java.lang.Class which is on the excluded list of classes (see above). Temporary solution is to copy the above into your struts.xml and remove java.lang.Class from the excluded classes.

Support for accessing static methods from expression will be disabled soon, please consider re-factoring your application to avoid further problems! Please check WW-4348.

OGNL is used to call action's methods

This can impact actions which have large inheritance hierarchy and use the same method's name throughout the hierarchy, this was reported as an issue WW-4405. See the example below:

public class RealAction extends BaseAction {  
    @Action("save")
    public String save() throws Exception {
        super.save();
        return SUCCESS;
    }
}    
 
public class BaseAction extends AbstractAction {
    public String save() throws Exception {
        save(Double.MAX_VALUE);
        return SUCCESS;
    }
}
 
public abstract class AbstractAction extends ActionSupport {
    protected void save(Double val) {
        // some logic
    }
}

In such case OGNL cannot properly map which method to call when request is coming. This is do the OGNL limitation. To solve the problem don't use the same method's names through the hierarchy, you can simply change the action's method from save() to saveAction() and leaving annotation as is to allow call this action via /save.action request.

  • No labels