HTML injection in Child item search on issue page leads to XSS on self hosted instances
:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.**
**[HackerOne report #2655757](https://hackerone.com/reports/2655757)** by `joaxcar` on 2024-08-14, assigned to @kmorrison1:
[Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce)
## Report
#### Summary
HTML injection in issue page when adding `Child item`. Leading to XSS on self-hosted instances without proper CSP
See this [code](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/work_items/components/shared/work_item_token_input.vue#L242)
```html
formatResults(input) {
if (!this.searchTerm) {
return input;
}
return highlighter(`<span class="gl-text-black-normal">${input}</span>`, this.searchTerm);
},
...
<div v-safe-html="formatResults(dropdownItem.title)" class="gl-text-truncate"></div>
```
where `dropdownItem.title` ends up in `v-safe-html`
This allows an attacker to inject any HTML that can get through DOMPurify to the page. As shown in https://hackerone.com/reports/2654010 its possible to use `svg/use` to bypass the current DOMPurify filter to gain XSS in Firefox and Safari.
#### Steps to reproduce
__!! Use Firefox/Safari !!__
1. Create a new group called `group1` (public)
2. Create a subgroup in `group1` called `assets` (public)
3. Open dev-tools and go to the `inspector` and search in the DOM for `assets/icons-` find any url that looks like this `/assets/icons-454317f5123bdb93dcb695c6092c458fb0ec6c862d0a56857aefa1c73469f743.svg#sidebar` (the long hash value will depend on the gitlab instance) copy the `icons-<hash>.svg` name
4. In `group1/assets/` create a project called `icons-<hash>.svg` (the full hash name from step 3) (public)
5. In the new project create a file called `test.svg` with this content
```svg
<?xml version="1.0"?>
<svg id="main" xmlns="http://www.w3.org/2000/svg">
<image href="1" onerror="alert(document.domain)" />
</svg>
```
5. Go back to the main group `group1` and create a new project called `project1` (public)
6. In `project1` create a new `issue`, call it `issue1`
8. When `issue1` is created you land on the issue page, now click `Add->New Task` and name the new `task`
```
<svg><use href="..\..\..\assets/icons-<hash>.svg/-/raw/main/test.svg#main"/></svg>
```
where you replace `<hash>` with the hash from step 3 (!! important)
9. Now go to `group1/project1/-/issues/new` again and create a new issue `issue2`
10. When the new issue is created click `Add->Existing Task`
11. The alert should pop
In an attack scenario, its a victim user that created the `issue2` but this shows the injection
In this image I have disabled CSP on gitlab.com
#### What is the current *bug* behavior?
User-controlled content is sent directly into `v-safe-html`
#### What is the expected *correct* behavior?
Task name should be HTML escaped
#### Impact
HTML injection on gitlab.com and XSS on self-hosted servers
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [Screenshot_2024-08-14_at_09.14.48.png](https://h1.sec.gitlab.net/a/8f192bf7-170f-46cc-8575-9ac3a35a8a87/Screenshot_2024-08-14_at_09.14.48.png)
## How To Reproduce
Please add [reproducibility information] to this section:
1.
1.
1.
[reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues
issue