Reflected XSS in Report Abuse Functionality
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
- Create two gitlab accounts called: Victim and Attacker
- Note id of each previously created user id
- 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 - Open the url in victim session
- 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: