Skip to content

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

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.

Related to #407883 (closed)

Merge request reports