Skip to content

Reflected XSS in Report Abuse Functionality

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #1941091 by akadrian on 2023-04-10, assigned to @ameyadarshan:

Report | Attachments | How To Reproduce

Report

Summary

The Report Abuse functionality which can be triggered for example from snippet comments is vulnerable to reflected xss.
Vulnereble url:
https://gitlab.com/-/abuse_reports/new?ref_url=javascript:alert(44);/%2Froot%2Fvictim-project1%2F-%2Fsnippets%2F3%23note_125&user_id=12743360
Vulnerable parameter: ref_url

Steps to reproduce
  1. Create two gitlab accounts called: Victim and Attacker
  2. Note id of each previously created user id
  3. Take following url and change user_id to Victim or Attacker id, in my case user_id=2 is an id of victim user:
    https://YOUR-HOST/-/abuse_reports/new?ref_url=javascript:alert(44);/%2Froot%2Fvictim-project1%2F-%2Fsnippets%2F3%23note_125&user_id=2
  4. Open the url in victim session
  5. Click on "Cancel" button and javascript should launch. On self-hosted gitlab there is no CSP- protection so it will be run without the need of bypassinng CSP. On SaaS gitlab version CSP will block this but you should see alert in console.
Impact

It's a reflected XSS issue which can lead to account takeover, making actions on user behalf.

What is the current bug behavior?

ref_url parameter value is reflected with no filtering applied which leads to XSS vulnerability

What is the expected correct behavior?

ref_url parameter value should be validated on server side allowing only http or https schemes. Also html encoding should be
applied to avoid script injection.

Impact

Attacker could exploit this vulnerability to make actions on user behalf or even steal access to victim accounts.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: