Webwork direct method invocation can bypass validatingStack through Action aliases

WebWork supports the concept of action aliases, which allow a single action class to serve requests mapping to different names. This allows a developer to reuse the same action logic, but provide different results based on interceptors. When an action is invoked, Webwork will typically call its execute() method, but this behavior can be modified in either xwork.xml or from a URL of the form “/dosomething!method.action”.

Two interceptor stacks that are of particular interest to Confluence:

• defaultStack – Provides all the basic interceptors such as transactions, params, and autowiring.
• validatingStack – Extends defaultStack with some additional security filters (ConfluenceXsrfTokenInterceptor, ConfluenceWorkflowInterceptor).

To make use of features like XSRF and framework validation, an Action is configured in xwork.xml with a reference to validatingStack. In cases where this protection is not needed, they are configured to reference defaultStack.

A security issues exists when aliases use different interceptor stacks for the same Action. By submitting requests to an Action using the defaultStack, an attacker can bypass XSRF and validation protections the validatingStack would provide.

A case study of this vulnerability is ChangeMyPasswordAction, defined in xwork.xml as follows:

 
<package name="users" extends="default" namespace="/users">
    <default-interceptor-ref name="validatingStack"/>
...
    <action name="changemypassword" class="com.atlassian.confluence.user.actions.ChangeMyPasswordAction" method="doDefault">
        <interceptor-ref name="defaultStack"/>
        <result name="input" type="velocity">/users/changemypassword.vm</result>
        <result name="error" type="velocity">/users/changemypassword.vm</result>
        <result name="success" type="velocity">/users/changemypassword.vm</result>
    </action>

    <action name="dochangemypassword" class="com.atlassian.confluence.user.actions.ChangeMyPasswordAction">
        <param name="RequireSecurityToken">true</param>
        <result name="input" type="velocity">/users/changemypassword.vm</result>
        <result name="error" type="velocity">/users/changemypassword.vm</result>
        <result name="cancel" type="redirect">viewmyprofile.action</result>
        <result name="success" type="velocity">/users/changemypasswordsuccessful.vm</result>
    </action>

Two aliases have been configured for the ChangeMyPasswordAction action. The “changemypassword” alias will use the defaultStack, which offers no additional security features, while the “dochangemypassword” alias will use the validatingStack, which provides XSRF and framework validation features.

The action itself is written as follows:

public class ChangeMyPasswordAction extends AbstractUserProfileAction implements FormAware
{
  private String currentPassword;
  private String newPassword;
  private String newPasswordConfirmation;
...
  public void validate()
  {
    if (!userAccessor.authenticate(getUser().getName(), currentPassword))
    {
      addActionError(getText("cur.pass.not.correct"));
    }
  }

  public String execute() throws Exception
  {
    try
    {
      userAccessor.alterPassword(getUser(),newPassword);
...
    return 

When invoked through normal means, the “changemypassword” action will execute doDefault, which simply renders the appropriate Velocity template for changing a user’s password. When the form is submitted, the “dochangemypassword” action is executed, which verifies XSRF tokens and validates the current password field is correct before changing a users password.

An attacker can exploit this action by submitting a request to “changemypassword”, but explicitly specifying the method to be executed in the URL. In this case, if they specify a URL like http://website.com/confluence/users/changemypassword!execute.action?newPassword=hacked&newPasswordConfirmation=hacked, then XSRF and current password validation will be bypassed.

This is a good example for demonstrating the two disadvantages in bypassing the validatingStack:

• An attacker can now conduct XSRF attacks against all Actions that should have been protected.
• An attacker can bypass any framework validation that is supposed to provide security and authorization checks.

The simplist way to mitigate this vulnerability is to remove the "!method" syntax support for invoking actions in Webwork.