-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
None
-
None
The ConfigurationAction.doSetCardColor method is vulnerable to persistent XSS when saving an unsanitized cardColor parameter. The vulnerability is triggered in several velocity templates during rendering:
- All-layouts.vm
- Card-layout.vm
- Issue-create.vm
- Issue-gadget-cardview.vm
- Issue-print.vm
- Issue.vm
- List-compact-layout.vm
- List-layout.vm
- Main.vm
- Ranking-page.vm
- Summary-layout.vm
- Task-options.vm
File: greenhopper\src\main\java\com\pyxis\greenhopper\jira\Actions\ConfigurationAction.java
package com.pyxis.greenhopper.jira.actions; import java.util.ArrayList; import java.util.Arrays; ... @SuppressWarnings("serial") public abstract class ConfigurationAction extends BoardAction { ... private String cardColor; ... @RequiresXsrfCheck public String doSetCardColor() { if(getCanEditConfig()) { getConfiguration().setCardColor(typeId, cardColor); getConfiguration().save(); } return doSuccess(); } ... public void setCardColor(String cardColor) { this.cardColor = cardColor; }
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
[JSWSERVER-9068] ConfigurationAction.doSetCardColor Persistent XSS
Alert also shows on:
- classic planning board
- gadget
- create issue page
- show legend on classic planning board
- configuration pages
When testing please "click around" to ensure it's fixed everywhere.
Steps to reproduce the bug easily:
1. Run Charles proxy
2. Go to any project in classic mode
3. Tools, configuration, then choose Card Styles tab
4. Change the card colour in the UI to anything
5. Catch the post in Charles, edit the form params and set cardColor to something like: '"/><script>alert("xss is evil")</script> and then execute the request again
6. Reload the page - alert pops up 
Apparently gadget velocity files have a different method to encode html. Updated to use $action.util.encodeHtml and it seems happy.
On branch
GHS-9068-xss