Rate this page:
This document describes changes that were made to the handling of XWork plugins in Confluence between versions 2.9 and 2.10. All developers writing XWork plugins for Confluence 2.10 and later should take note of this.
XWork allows the setting of complex parameters on an XWork action object. For example, a URL parameter of formData.name=Charles
will be translated by XWork into the method calls getFormData().setName("Charles")
by the XWork parameters interceptor. If getFormData()
returns null, XWork will attempt to create a new object of the appropriate return type using its default constructor, and then set it with setFormData(newObject)
.
This leads to the potential for serious security vulnerabilities in XWork actions, as you can effectively call arbitrary methods on an Action object. This led to the Parameter Injection issues in Confluence Security Advisory 2008-10-14. In Confluence 2.9 this issue was worked around by filtering out all properties that were known to be dangerous, but for 2.10 a more complete solution that also protects against future vulnerabilities has been introduced.
Because this vulnerability (and its solution) can affect plugins, plugin authors must now take extra steps to support complex form parameters.
From Confluence 2.10 and onwards, complex parameters are not permitted unless they are accompanied by a Java-level annotation declaring that the parameter is "safe" for XWork to access. There are two ways to apply the annotation:
@com.atlassian.xwork.ParameterSafe
annotation, that method is accessable as a complex parameter@com.atlassian.xwork.ParameterSafe
annotation, any complex parameter that is of that type is accessibleOnly the initial method on the XWork action, or initial return value from the action class needs to be annotated, nested complex parameters do not need further annotation.
So in the example above, to make the formData parameter you would do one of the following:
1 2@ParameterSafe public FormData getFormData() { return formData; }
or:
1 2@ParameterSafe public class FormData { ... }
By placing the @ParameterSafe
annotation on a method or class, you the developer are declaring that you have carefully inspected that code for potential vulnerabilities. Things to be careful of:
Your safest bet is that if you are using an object to store complex parameters, make it a dumb: just setters that store state in the object itself and no further behaviour. Any more functionality than that is dangerous.
Rate this page: