## Problem to solve GitLab accepts user URLs for a variety of reasons. When we can, we use `Gitlab::HTTP` which is secure by default and protects against SSRF and DNS Rebind attacks [1]. In some places, we use Faraday instead of `Gitlab::HTTP`. We also use third-party ruby gems which depend on Faraday. This creates a potential for vulnerabilities, and [these vulnerabilities have been exploitable in the past](https://gitlab.com/gitlab-com/gl-security/security-department-meta/-/issues/292). The problem is: how can we keep using Faraday / third party gems, while also protecting ourselves against attacks? **Note:** There are no exploitable vulnerabilities; this is a defense in depth measure. ## Proposal - [x] (In-progress) Create [a Faraday adapter](https://lostisland.github.io/faraday/adapters/write_your_adapter) which uses `Gitlab::URLBlocker` to resolve a DNS record to an IP address, and validate that the IP address is allowed + Using `UrlBlocker` and `Gitlab::CurrentSettings.` we can honour the network settings defined by admins, incl. "allow localhost", "allow local network", and "ip allow lists" [2] + MR here: https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/2298 - [x] Review by staff engineer to identify far-reaching impacts + https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86321#note_934117832 + Decision was to create epic with child issues and approach in a more iterative way - [ ] Create an adoption Issue for each part of the codebase + [x] oauth2 integrations will be first cab off the rank + [ ] Importer(s) + [ ] Prometheus + [ ] Elastic + [ ] Geo + [ ] ... - [ ] Create issue to set `Faraday.default_adapter = Gitlab::Faraday::HTTPConnectionAdapter` (secure by default) - [ ] Identify any areas where `Faraday.default_adapter` is overridden, and create issue to address ## Background ### Our own code using Faraday |Code|URL|Comments| |----|---|--------| |`ObjectStorage`|https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/uploaders/object_storage.rb#L286-288|| |`ContainerRegistry::BaseClient`|https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/container_registry/base_client.rb| Seems like Container Registry base URL is defined as a static config variable, so no risk there. | |QA's `Environments::Base`| https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/contracts/provider/environments/base.rb|| |`Tooling::MergeRequest`| https://gitlab.com/gitlab-org/gitlab/-/blob/master/tooling/merge_request.rb|| ### Gems using Faraday |Gem|Comments| |---|-------------------------------| |`acme-client`|| | ~~`asana`~~ | Removed | |`azure-storage-common`|/!\ Also depends on `net-http-persistent`| |`danger`|/!\ Also depends on `faraday-http-cache`| |`elasticsearch-transport`| /!\ Do we need to allow code-based overrides of configured network settings? Elastic is frequently hosted on local networks| |`google-cloud-env`|| |`googleauth`|| |`google-api-client` -> `signet`|| |`graphlient`|https://github.com/ashkan18/graphlient#swapping-the-http-stack| |`ms_rest`|| |`ms_rest_azure`|| |`oauth2`|Big impact (see below)| |`octokit`|| |`sawyer`|| |`sentry-raven`|| |`signet`|| |`test_file_finder`|| |`omniauth-atlassian-oauth2` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-auth0` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-authentiq` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-azure-activedirectory-v2` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-azure-oauth2` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-dingtalk-oauth2` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-facebook` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-github` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-gitlab` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-google-oauth2` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-oauth2-generic` -> `ominiauth-oauth2` -> `oauth2`|| |`omniauth-salesforce` -> `ominiauth-oauth2` -> `oauth2`|| --- As this issue does not relate to exploitable vulnerabilities, and the class of vulnerability is widely known, and this is defense in depth, I'll make this public. [1]: https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#server-side-request-forgery-ssrf [2]: https://docs.gitlab.com/ee/security/webhooks.html