Persistent XSS on public project page
Proof of concept
Follow these steps to reproduce:
- go to /projects/new, fill in the form and set the visibility level to Public
- now click Settings, followed by Services and Custom Issue Tracker
- now fill in the form like this:
- as you can see, the XSS payload is hidden in the Project URL:
- go back to the project page and click Issues, this triggers the XSS:
Origin of the issue
The integration model lacks a validator that makes sure the Project URL matches /\Ahttps?:///i. This validator should also be applied to the Issues URL and New issue URL, since those fields are also vulnerable to a persistent XSS (although those are not on the project page).
I just noticed that this XSS is also possible with the JIRA integration. If the XSS payload is entered in the Project URL field, like you can see in the attached screenshot, it behaves the same as the issue that I initially reported. My suggestion would be to do a proper root cause analysis to make sure all integrations are protected against this vulnerability.