Filter HTTP requests that are not specific to git operations

[coopernetes]

Is your feature request related to a problem? Please describe.
Currently, git-proxy via its express http proxy middleware is acting as a transparent proxy to https://github.com. There is business logic in place that restricts certain actions a git client make take (push a commit to a repo, pull a repo, etc). However, when a user visits a Git Proxy deployed server via the browser, there is no restrictions in place due to some fallback logic. As such, Git Proxy's middleware will permit the request to the upstream web server (GitHub) via the browser.

Given that this is meant to enforce git protections via pushes & pulls, Git Proxy should not permit web access through a browser by default. In most scenarios, git-proxy is deployed behind a corporate firewall and this presents path out of an organization that is not captured, filtered or inspected by the current proxying. This can be used to bypass a network perimeter, exfiltrate data with other GitHub services like gists, etc.

Describe the solution you'd like

1. When a user is pushing or pulling code through Git Proxy using any compatible git client, the proxy operates as it certain does and uses the list of Actions to apply filtering and protections on git interactions.
2. When a user visits a Git Proxy server in the browser to attempt to browse GitHub via https://git-proxy.example.com, they should receive an error.

Git Proxy can filter out the following properties of the inbound HTTP request:

• The server should perform content negotiation¹ and reject requests that do not contain an Accept header matching the content types of application/x-git-* (multiple values are used²³). Clients making requests from the browser with an Accept header of text/html should be rejected.
• The server should only permit requests matching known "safe URL paths" used by git clients such as /info/refs?service=git-receive-pack & /git-receive/pack for pushes and /info/refs?service=git-upload-pack & /git-upload-pack for pulls.
• The error response should be a 400 Bad Request and return some minimal information such as "invalid request". The response should be minimal so as to not introduce potential security issues. At most, the server can respond with a 415 Unsupported Media Type.

Describe alternatives you've considered
You could deploy a reverse proxy in front of Git Proxy to handle this filter (via nginx). However, given that git-proxy is "git aware" and applies application-level filtering on git operations, it should apply this as a default.

Other networking solutions likely are available to apply filtering at the infrastructure layer but those appliances generally cannot implement git application logic to restrict access. Git Proxy is typically deployed as a trusted system and is permitted through firewalls, etc.

Additional context
N/A

Footnotes

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation ↩

2. https://www.git-scm.com/docs/http-protocol ↩

3. https://github.com/git/git/blob/master/http-backend.c ↩

[JamieSlome]

@coopernetes - nice break down of the problem and overview of the solution space 🚀

I wonder if this behavior should be configurable and if we expose new config + docs for enabling/disabling "git-only" traffic. I think that some organisations or users may want to allow certain HTML, or otherwise, requests through the proxy.

[coopernetes]

I wonder if this behavior should be configurable and if we expose new config + docs for enabling/disabling "git-only" traffic. I think that some organisations or users may want to allow certain HTML, or otherwise, requests through the proxy.

Having this configurable is reasonable. Secure by default would be my preferred approach.

I'll admit, it still makes me uncomfortable to position git-proxy, as it's currently implemented, as a full-blown reverse proxy for all things GitHub. I wouldn't say it's the best use of the project since we're trying to both a) become more neutral in the SCM providers we support to include open source projects hosted outside of GitHub ie. GitLab, BitBucket, and b) solve for the git application security & compliance logic. A lot of the work has already begun via #335

As a consequence, I'm going to close #305 since that is more specialized and is unique to each organization. This can be accomplished using any variety of reverse proxies (nginx) or other network appliances.

As an alternative, can we add a different code path (via a separate URL on Express) to facilitate that sort of connectivity? Something like:

router.use(
  '/github-web', proxy('https://github.com', (req, res) => {
    filter: async function (req, res) {
      // disallow git pushes, etc.
      if (req.headers['accept'].startswith('application/x-git')) {
        res.status(415).send('unsupported media type');
        return;
      }
      // permit other traffic such as browser requests
      ...
    }
  })
)

[JamieSlome]

@coopernetes, I agree with you; "secure by default" makes sense. Let's leave the configuration out of this for now. I'll review #415 today and we can get this feature merged 👍