- Upgrading Struts 1.2.8 to Struts 1.2.9
- Bug 38374 - Validation always skipped with Globals.CANCEL_KEY
- Bug 38534 - DOS attack, application hack
- Bug 38749 - XSS vulnerability in DispatchAction
- EventDispatchAction and EventActionDispatcher
- Commons Validator
1. Upgrading Struts 1.2.8 to Struts 1.2.9
N.B. The primary motivation for Struts 1.2.9 was to fix three security issues which have been identified - see below for more details. For full details of changes in version 1.2.9 see the Release Notes.
Only the struts.jar needs to be upgraded - all Struts dependencies remain the same as Struts 1.2.8. The only other requirement to upgrade is the new Cancel processing - see secutiry issue 2.1 Bug 38374 - Validation always skipped with Globals.CANCEL_KEY below.
2. Security Issues
2.1. Bug 38374 - Validation always skipped with Globals.CANCEL_KEY
2.1.1. Issue: Cancel Processing
The Struts <html:cancel> tag sets a request parameter (org.apache.struts.taglib.html.Constants.CANCEL) which causes validation to be skipped.
Spoofing this request parameter however, could be used maliciously in order to circumvent an applications validation and proceed with the request processing with erroneous and potentially damaging data.
See Bug 38374 for full details.
2.1.2. Resolution: Cancellable Property
A new cancellable property has been introduced which indicates whether an action is allowed to be cancelled or not. In Struts 1.2.9 this is set to true or false for an action in the struts-config.xml using the <set-property> notation. From Struts 1.3.x a new cancellable attribute has been added to the <action> element.
Now any action where the cancellable property is not set to true will throw an InvalidCancelException.
2.1.3. Upgrade Implications
Any existing applications that use the Cancel processing will need to modify their struts-config.xml to set the cancellable property for actions which require it.
In Struts 1.2.9 the <set-property> is used to set the cancellable property for an action....
<action path="/fooAction" input="/foo.jsp" validate="true"> <set-property property="cancellable" value="true"/> <forward name="success" path="/bar.jsp"/> </action>
From Struts 1.3.x a new cancellable attribute can be used....
<action path="/fooAction" input="/foo.jsp" validate="true" cancellable="true"> <forward name="success" path="/bar.jsp"/> </action>
In both Struts 1.2.9 and Struts 1.3.x an exception handler can be configured to handle the InvalidCancelException
<action path="/fooAction" input="/foo.jsp" validate="true" cancellable="true"> <forward name="success" path="/bar.jsp"/> <exception key="errors.cancel" type="org.apache.struts.action.InvalidCancelException" path="/foo.jsp"/> </action>
2.1.4. Test Cases
This bug was tested using the struts-examples webapp (see struts-examples.war in the binary distribution). If you fire up the examples webapp, select the Taglib Test Pages link, then select the <html:cancel> link you will be presented with a page where you can try the Cancel button for four different configurations.
2.2. Bug 38534 - DOS attack, application hack
2.2.1. Issue: Denial of Service (DOS)
ActionForm's which involve multipart handling expose the MultipartRequestHandler through the form's getMultipartRequestHandler() method - this in turn gives access to the ActionServlet and through that to the ServletContext. Appropriately named request parameters could be spoofed in order to set attributes in the ServletContext during form population. For example Struts configuration objects stored in ServletContext could be replaced rendering the application inoperable.
See Bug 38534 for full details.
2.2.2. Resolution: Remove MultipartRequestHandler until after Form Population
From Struts 1.2.9 the MultipartRequestHandler is only stored in the ActionForm after the form population has been completed. Malicious use of this mechanism in a DOS attack will now result in a NestedNullException being throw by BeanUtils during form population.
2.2.3. Upgrade Implications
None - simply upgarding to Struts 1.2.9 or later removes the ability for someone to launch a DOS attack in this way.
2.2.4. Test Cases
This bug was tested in two ways:
New test case for RequestUtils.populate() - The TestRequestUtilsPopulate test case was added with the testMultipartVisibility() test for this bug.
Using the struts-examples webapp - (see struts-examples.war in the binary distribution). If you fire up the examples webapp, select the Upload Examples link - at the bottom of the page there is a specific test for Bug 38534. To prove that the bug is fixed:
- Try the test for Bug 38534 in the Struts 1.2.9 version of the struts-examples webapp.
Drop the Struts 1.2.9 version of upload.jsp into the Struts 1.2.8 version of the struts-examples webapp and see the devastation caused by the bug without the fix applied.
2.3. Bug 38749 - XSS vulnerability in DispatchAction
2.3.1. Issue: Cross Site Scripting (XSS) Vulnerability
DispatchAction (and ActionDispatcher) were rendering user input when throwing an exception for invalid user input, which could be used to launch a XSS attack.
See Bug 38749 for full details.
2.3.2. Resolution: User Input No Longer Rendered
DispatchAction and ActionDispatcher have been modified to no longer render user input.
2.3.3. Upgrade Implications
None - simply upgarding to Struts 1.2.9 or later removes this vulnerability.
2.3.4. Test Cases
DispatchAction and ActionDispatcher were both tested to ensure that user input was no longer being rendered in the error messages - however, no test cases were added to the Struts code base for this bug.
3. EventDispatchAction and EventActionDispatcher
4. Commons Validator
Struts 1.2.9 is distributed with Commons Validator 1.1.4. However you may wish to upgrade to the latest version of of Validator to take adavantage of new features or bug fixes. The current release of Validator (as of 24 March 2006) is 1.3.0...