Skip to content

HTMLi in new gitlab application Oauth page (/oauth/authorize) leading to ATO

⚠ 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 #2567533 by joaxcar on 2024-06-20, assigned to @cmaxim:

Report | Attachments | How To Reproduce

Report

Summary

There is an HTML injection and XSS in the new https://gitlab.com/oauth/authorize page.

Sorry for the sparse report. Found this when I was supposed to go to bed. The XSS outlined here will only trigger without CSP but I hope to be able to bypass it when I wake up

Steps to reproduce

  1. Go to https://gitlab.com/oauth/applications
  2. Create a new application with the name <img src=x onerror=alert(1)> add the other fields. Redirect URL as https://example.com and scope as api
  3. Click create, take note of the application ID
  4. Now visit (replace APP ID)
https://gitlab.com/oauth/authorize?client_id=APP_ID&redirect_uri=https://example.com&response_type=code&scope=api

Open devtools and see the XSS blocked by CSP on gitlab.com, firing on self hosted

Screenshot_2024-06-21_at_00.49.26.png

Impact

Stored XSS

What is the current bug behavior?

Application name rendered without sanitization

What is the expected correct behavior?

Name should be sanitized.

Output of checks

This bug happens on GitLab.com

Impact

Stored XSS

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: