Reflected XSS in OAuth Authorize window due to redirect_uri allowing arbitrary protocols
Link: https://hackerone.com/reports/303405 By: @fransrosen
When creating an application as a user in a GitLab-instance, any user on the same instance can authorize the application. This means the Authorize-page can be shown for anyone with the content from the application one user has created.
When adding Callback-urls for an application, there's no validation for the protocol (most likely because it can be used for more than
http(s). The problem is that it now allows you to set a callback to
which is a valid URI to trigger the alert (since
%250a is a URL-encoded new line.
So, creating an application as a regular user with the following info:
Name: Totally Legit App
And then using the APP-id you get, creating the following URL (with your instance domain as prefix):
you will see this:
Clicking in this case on
The proper mitigation to this is to prevent
Even though this is per definition a stored XSS, it seems like the
redirect_uri is forced to be in the URL with exact match, which gives away that there's something running and also converts a bit into a reflected XSS (since you cannot hide the payload). However, it actually doesn't trigger the XSS-auditor in Chrome, so the payload will still work for all browsers without any bypass.