Internal Open Redirection Due to Improper handling of "../" characters
# :warning: Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.
**[HackerOne report #1889230](https://hackerone.com/reports/1889230)** by `akadrian` on 2023-02-28, assigned to `GitLab Team`:
[Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce)
## Report
##### Summary
Following endpoint takes multiple parameters as input.
/<namespace>/<project>/-/refs/switch
It was discovered that using at least "ref" and "path" parameters its possible to influence "Location" header value in response in such way that may lead to redirection to other projects.
##### Steps to reproduce
(Step-by-step guide to reproduce the issue, including:)
1. Create Victim Project called "victim-project" under "victim" user namespace
2. Open following URL: http://gitlab.example.com/victim/victim-project/-/refs/switch?ref=main/../&path=../../../../../attackproj
3. You will notice that project was redirected to http://gitlab.example.com/attackproj
4. It works on gitlab.com as well
##### Impact
It can be used to create malicious links to direct other users to other projects. It could lead to data theft for example. Imagine scenario where attacker creates Issue with the link stating that JIRA integration has incorrect password. Link is correct at the first sight yet it is redirecting to other projects.
##### What is the current *bug* behavior?
Special characters are not properly sanitized. It is possible to create "../" sequence and influence Location header with custom path leading to internal redirection.
##### What is the expected *correct* behavior?
"../" characters should be encoded so that browser would not interpret the sequence as valid pathname.
#### Impact
It can be used to create malicious links to direct other users to other projects. It could lead to data theft for example. Imagine scenario where attacker creates Issue with the link stating that JIRA integration has incorrect password. Link is correct at the first sight yet it is redirecting to other projects.
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [recording-1677616925853.webm](https://h1.sec.gitlab.net/a/b24dc10e-66f1-432a-aa2c-7f1f30634614/recording-1677616925853.webm)
## How To Reproduce
Please add [reproducibility information] to this section:
1.
1.
1.
[reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues
### Proposal
1. Disallow `../` in `path` parameter for `/-/refs/switch` endpoint. We have utils we can use https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#gitlab-specific-validations
2. Check that `path` parameter for other endpoints that uses `extract_ref_path` https://gitlab.com/gitlab-org/gitlab/-/issues/395437#note_1373513270
~Alternatively, we check that the `path` does not result in path expansion beyond the root directory of the repository.~
issue