Persistent XSS on public project page

Details

A project admin can set up a custom issue tracker integration. This setting misses a check to make sure that it's a real URL and, thus, can use the javascript handler to execute arbitrary Javascript. Browsers use this handler to execute inline Javascript. This can lead to an account take over via the leaked API token.

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:

javascript:alert("Current user its API token: " + window.gon.api_token);

go back to the project page and click Issues, this triggers the XSS:

Impact

GitLab doesn't have a content security policy, which means that clients allow inline Javascript to be executed. This gives, like shown in the proof of concept, access to the current user its API token. The API token can be used to access the user its projects, do actions as the user, give access to potential confidential information, etc.

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).

Another exposure

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.

/cc @jschatz1