• Type: Bug
• Resolution: Fixed
• Priority: High
• Fix Version/s: 2.6.1
• Affects Version/s: 2.5.7
• Component/s: None
• Labels:

  • affects-server
  • security
• Environment:

  Solaris 10, JDK 1.5.0_12, SunOne WebServer 6.1 SP8

1. appscan.wiki.doc

   361 kB

   14/Sep/2007 2:49 PM

2. printable-icon-xss.patch

   1 kB

   08/Oct/2007 6:13 AM

3. wiki.appscan.doc

   118 kB

   13/Sep/2007 8:15 AM

[CONFSERVER-9456] XSS Bug in printable link display

Collapse comment: Matt Ryall added a comment - 08/Oct/2007 6:13 AM

Matt Ryall added a comment - 08/Oct/2007 6:13 AM

Fix is verified on our internal SSL server (extranet).

I've attached a patch for this issue. It will also be fixed in Confluence 2.6.1, which is due to be released in approximately two weeks.

This patch is based off the source, so you'll need to use patch's -p option to remove the leading paths down to just template/includes/macros.vm.

Expand comment: Matt Ryall added a comment - 08/Oct/2007 6:13 AM

Matt Ryall added a comment - 08/Oct/2007 6:13 AM Fix is verified on our internal SSL server (extranet). I've attached a patch for this issue. It will also be fixed in Confluence 2.6.1, which is due to be released in approximately two weeks. This patch is based off the source, so you'll need to use patch's -p option to remove the leading paths down to just template/includes/macros.vm .

Collapse comment: m@ (Inactive) added a comment - 03/Oct/2007 3:43 AM

m@ (Inactive) added a comment - 03/Oct/2007 3:43 AM

Wyatt,

At first I could not reproduce this issue on 2.5, 2.6 or our 2.7 development branch. I took a look at our templates and could see that the URL's were not properly escaped. So I was at a loss to explain what was happening.

I eventually managed to reproduce this issue against an internal server of ours which was using a HTTPS reverse proxy. It's possible the issue was affected by the HTTPS reverse proxy configuration (which is why I could not reproduce on the HTTP servers).

I have patched the templates to escape the URL which should address this particular situation. I will close this issue after I've seen it working via HTTPS.

Cheers
Matt

Expand comment: m@ (Inactive) added a comment - 03/Oct/2007 3:43 AM

m@ (Inactive) added a comment - 03/Oct/2007 3:43 AM Wyatt, At first I could not reproduce this issue on 2.5, 2.6 or our 2.7 development branch. I took a look at our templates and could see that the URL's were not properly escaped. So I was at a loss to explain what was happening. I eventually managed to reproduce this issue against an internal server of ours which was using a HTTPS reverse proxy. It's possible the issue was affected by the HTTPS reverse proxy configuration (which is why I could not reproduce on the HTTP servers). I have patched the templates to escape the URL which should address this particular situation. I will close this issue after I've seen it working via HTTPS. Cheers Matt

Collapse comment: Matt Ryall added a comment - 13/Sep/2007 11:01 PM

Matt Ryall added a comment - 13/Sep/2007 11:01 PM

Setting fix-for.

This is in the printable-view icon on the 404 page, which uses the path of the request URL without correctly escaping it.

Expand comment: Matt Ryall added a comment - 13/Sep/2007 11:01 PM

Matt Ryall added a comment - 13/Sep/2007 11:01 PM Setting fix-for. This is in the printable-view icon on the 404 page, which uses the path of the request URL without correctly escaping it.

Collapse comment: Per Fragemann [Atlassian] added a comment - 13/Sep/2007 8:24 AM

Per Fragemann [Atlassian] added a comment - 13/Sep/2007 8:24 AM

Thanks for your feedback, we will look into this as soon as possible

Cheers, Per

Expand comment: Per Fragemann [Atlassian] added a comment - 13/Sep/2007 8:24 AM

Per Fragemann [Atlassian] added a comment - 13/Sep/2007 8:24 AM Thanks for your feedback, we will look into this as soon as possible Cheers, Per