-
Bug
-
Resolution: Fixed
-
Medium
-
None
-
7.5
-
Scope of this issue is to address two specific XSS vulnerabilies. The scope of fixing i18n parameters is tracked elsewhere. Please see the comment below for details.
(Original Description)
The ConfluenceActionSupport.getText method is annotated with @HtmlSafe, forcing the Velocity engine to skip HTML encoding of the methods response. The responsibility of HTML encoding is therefore placed on the caller.
There appears to be a common vulnerability in several velocity templates, that take a user controlled variable and pass it as an argument to the getText method without encoding, leading to XSS vulnerabilities.
Two such examples are:
#if ($justAdded) #applyDecorator("warning" "") $action.getText("added.exclusion.feedback", [$justAdded, "$req.contextPath/admin/purgesinglereferrer.action?referrer=$justAdded", "$req.contextPath/admin/purgereferrers.action"]) #end #end
<fieldset class="group"> <legend><span>$action.getText("office.connector.docimport.whereto"):</span></legend> <div class="radio"> <input type="radio" id="newpage" class="radio flip-delete" name="importSpace" value="true" checked> <label for="newpage">$action.getText("office.connector.docimport.whereto.space", [$pageTitle])</label> </div> <div class="radio"> <input type="radio" id="overwritepage" class="radio flip-delete" name="importSpace" value="false"> <label for="overwritepage">$action.getText("office.connector.docimport.whereto.page", [$pageTitle])</label> </div> <div class="checkbox" id="deletealldiv"> <input class="delete-all checkbox" type="checkbox" id="deleteall" name="overwriteAll" value="true" disabled> <label for="deleteall" id="deletealllabel" class="cannot-execute">$action.getText("office.connector.docimport.whereto.delete", [$pageTitle])<label> </div> </fieldset>
It's recommended all callers of the getText() method require HTML encoding of user controlled parameters.
- mentioned in
-
Wiki Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFCLOUD-54069] Fix XSS vulnerabilities in managereferrers.vm and importword.vm
Note about the "fixed version":
From etom:
The issue refers to two problems. The first was fixed in 4.3.6 and for the second, it's harder to track down when we stopped setting the property. So we know for certain that the second vulnerability is gone in 5.1.1 because that's when I removed the property entirely.
FYI in Manager Referrers, I've QA'ed and the form still works. Feel free to add my name as a reviewer if need be.
I've investigated the issue and it appears that:
- The $justAdded parameter in managereferrers.vm is no longer set anywhere in the code, which means that the condition of the if block is never met and this shouldn't be an XSS vulnerability. I've removed references to the parameter and the call to getText.
- The importword.vm vulnerability was fixed as part of
CONF-26221(#set($pageTitle = $generalUtil.htmlEncode($page.title))).
I've confirmed with dblack that the scope of this issue is to fix two specific XSS vulnerabilities:
- managereferrers.vm
- importword.vm
The broader problem described in the description of this issue is tracked by CONF-15548, which should be scheduled as feature work due to its complexity (cc: smansour).
Dan Hodson
added a comment - Example screenshot of persistent XSS. Dan Hodson
added a comment - Example screenshot of reflected XSS. 
How we can patch the 4.3.7 version to fix these XSS vulnerabilities?
We don't want to do upgrade to the 5 version..
Thank you in advance.