User can add project to job token scope allowlist without having any role in allowed project via POST /api/v4/projects/{id}/job_token_scope/allowlist

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 #2076075 by ricardobrito on 2023-07-19, assigned to @cmaxim:

Report | How To Reproduce

Report

Hi team,

with the release of Gitlab 16.1, it is now possible to manage the CI-CD job token scope using the REST API. According to the documentation:

You can add projects to the allowlist for a project. Projects added to the allowlist can make API calls from running pipelines by using the CI/CD job token. Prerequisite:

  • You must have at least the Maintainer role in the current project and at least the Guest role in the allowed project.

I have found that the endpoint http://YOUR-GITLAB-INSTANCE/v4/projects/:id/job_token_scope/allowlist does not validate whether the user making the request has at least guest role in the allowed project. If this is the expected behavior then there should be a DOCUMENTATION UPDATE (THIS IS IN SCOPE HACKERONE TRIAGER) that specifies that if the allowed project is inside a public group, the user making the request does not need to have at least guest role in the allowed project. If this is not the expected behavior there should be some permission enforcement in the endpoint.

Steps to reproduce

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

  1. Create Project A with user A, make it public/private (doesn't matter) - keep track of the project-id
  2. Create Group B with user B and create project B inside Group B with user B (both project and group are public).
  3. As user A make the following POST request to the endpoint: http://YOUR-GITLAB-INSTANCE/v4/projects/:id/job_token_scope/allowlist
  • :id is the id of project A.

In the JSON body of the request place the following content:
{"target_project_id":SOME-ID}
where SOME-ID is the id of the project B
4. Send the request and you should get something like this:

{
    "source_project_id": PROJECT-A-ID,  
    "target_project_id": PROJECT-B-ID  
}

Which confirms that the request completed successfully.

Expected Behavior

User A does not have at least guest role in project B, so he should not be allowed to set it as the allowed project, or if this is the expected behavior then there should be a DOCUMENTATION UPDATE.

Impact

A user who does not have at least guest role in the allowed project is capable of setting it as an allowed project using the endpoint http://YOUR-GITLAB-INSTANCE/v4/projects/:id/job_token_scope/allowlist.

How To Reproduce

Please add reproducibility information to this section: