Fix Maven request forward vulnerability to response splitting
What does this MR do and why?
🍀 Context
Similar to Open Redirection Through HTTP Response Splitting (#389328 - closed), the Maven Repository is vulnerable to response splitting.
🔧 How to reproduce
Create a public project
Curl
curl -vvv "http://gdk.test:3000/api/v4/projects/<project_id>/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/%0d%0ahttp:/%2fexample.com?test"
* Trying 172.16.123.1:3000...
* Connected to gdk.test (172.16.123.1) port 3000 (#0)
> GET /api/v4/projects/<project_id>/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/%0d%0ahttp:/%2fexample.com?test HTTP/1.1
> Host: gdk.test:3000
> User-Agent: curl/7.87.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-Security-Policy: default-src 'none'
< Content-Type: text/plain
< Location: http://example.com
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: 01GYCNPD7NHJMC1XTG5N3QPPEF
< X-Runtime: 0.107840
< Date: Wed, 19 Apr 2023 11:51:44 GMT
< Content-Length: 153
<
This resource has been moved temporarily to https://repo.maven.apache.org/maven2/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/
* Connection #0 to host gdk.test left intact
http://example.com.%
Location: http://example.com
-> This is not a redirect maven central
🔮 Other considerations
The request forward for Maven Repository is behind a feature flag that is currently disabled on gitlab.com.
Here is the rollout issue: https://gitlab.com/gitlab-org/gitlab/-/issues/359553
🚒 Solution
- Add the file path validation to
path
&file_name
params in the params helper path_and_file_name
We have 4 endpoints that use path_and_file_name:
GET /api/v4/packages/maven/\*path/:file_name
GET /api/v4/groups/:id/-/packages/maven/\*path/:file_name
GET /api/v4/projects/:id/packages/maven/\*path/:file_name
GET /api/v4/projects/:project_id/dependency_proxy/packages/maven/\*path/:file_name
🔬 How to set up and validate locally
Calling any of the above endpoints now using a malformed path
or file_name
will result in a 400 Bad Request
response with a validation error:
Curl
curl -vvv "http://gdk.test:3000/api/v4/projects/<project_id>/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/%0d%0ahttp:/%2fexample.com?test"
* Trying 172.16.123.1:3000...
* Connected to gdk.test (172.16.123.1) port 3000 (#0)
> GET /api/v4/projects/<project_id>/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/%0d%0ahttp:/%2fexample.com?test HTTP/1.1
> Host: gdk.test:3000
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache
< Content-Length: 49
< Content-Security-Policy: default-src 'none'
< Content-Type: application/json
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Gitlab-Meta: {"correlation_id":"01HBDXRYXPV9RZACBEMQ3DEKVG","version":"1"}
< X-Request-Id: 01HBDXRYXPV9RZACBEMQ3DEKVG
< X-Runtime: 5.358233
< Date: Thu, 28 Sep 2023 12:56:19 GMT
<
* Connection #0 to host gdk.test left intact
{"error":"file_name should be a valid file path"}
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #407883 (closed)