Persistent XSS via e-mail when adding an approver to a merge request
HackerOne report #496973 by mario-areias
on 2019-02-16, assigned to asaba
:
Summary:
The vulnerability consists in the ability to create branch names that contain characters such as <>/
. This branch name is sent via e-mail which is rendered as HTML.
Description:
One way to exploit this is by forking a repository. Then an attacker would create a branch called <script>alert(1)</script>
and make a simple change. Now the attacker creates a merge request to the original repository and assign a reviewer to it. The reviewer will receive the e-mail with the branch name not sanitised.
Another way to exploit is to by adding Gitlab users to a repository the attacker controls and assign them to review merge requests.
Steps To Reproduce:
Note: These instructions work on GDK with the latest version. I wasn't sure if it is allowed to test something like on gitlab.com
- Choose a public repository and fork it (let's say HTML5 boilerplate)
- Go through the repository main page http://yourserver:3000/root/html5-boilerplate
- Click on the button + button and select New File
- Create any file but choose a different target branch (something like
<script>alert(1)</script>
- Gitlab will direct you to a page to create a new merge request from your recently create branch to master. Ignore that.
- Open a New Merge Request
- Select Source Branch as your fork and the recently created branch
- As for Target branch select the original repo and master
- Click submit
- Select one the maintainers of the original repo
- Submit
- Go to letter opener (/rails/letter_opener/)
- See the alert popping up.
The steps above only require UI, but an attacker can create a branch name through git client as well. The create branch option UI protects against this attack.
There is also another version of the attack, where a repository owner can add any Gitlab users to become members of her repo. The attacker now create a Merge Request in his own repo and assign the new member to it. Same result.
Supporting Material/References:
- Vulnerable code at
gitlab-ce/app/views/notify/new_merge_request_email.html.haml
line 6. This is the exploit above. - Vulnerable code at
gitlab-ce/app/views/notify/repository_push_email.text.haml
line 49. I haven't created an exploit for this one, but I would assume it should be similar.
Impact
E-mail clients nowadays are well protected against XSS. However, a malicious user could use Gitlab's name to mislead users. The problem with this vulnerability is the reach. It is my understanding, an attacker can add whoever is a Gitlab user as a member of her own repo. So she could send malicious e-mails to them. I would usually say that is a low vulnerability, however, given the number of users that could be affected I would say is a medium