If you’re developing with GitLab or exposing websites with GitLab Pages, a serious security flaw called CVE-2023-0042 may affect your projects. This vulnerability, disclosed in early 2023, lets attackers craft links on GitLab Pages that redirect users to _any protocol_. That means an unsuspecting click could ship your visitors off to a _malicious_ chrome-extension://, ftp://, or even javascript: address.

Let’s break down this vulnerability, see how it can be exploited, and learn how to defend your apps, step-by-step with code examples and references.

What’s the Issue?

Between GitLab 11.4 and before 15.5.7, 15.6 < 15.6.4, and 15.7 < 15.7.2, a key input validation bug lets public GitLab Pages:

- Accept redirects to URLs that aren’t restricted to safe protocols like https:// or http://

This breaks user safety expectations. If someone convinces a visitor to click on a rogue link, that could trigger harmful behaviors or phishing attacks.

Example Scenario: A link on a GitLab Page sends a user to javascript:alert(document.cookie), causing their browser to execute unwanted JavaScript.

`

Click here to see a surprise!

3. GitLab Pages processes the redirect and sends the browser to ftp://evil.example.com.

Attackers can use protocols that are dangerous outside web navigation, such as mailto:, javascript:, or custom application protocols.

Minimal Proof-of-Concept Example

Suppose your GitLab Pages site has a redirect endpoint:
site.example.com/redirect/?target=ftp://malicious.com

A vulnerable (bad!) router in Ruby might look like

# BAD: does not filter protocols
class RedirectController < ApplicationController
  def to_target
    target = params[:target]
    redirect_to target
  end
end

An attacker supplies ?target=javascript:alert(1) or any scheme (ftp://, file://, etc).

Browser Exploits: Some protocols (data:, javascript:, etc) can run scripts.

- User Confusion: Users expect only website URLs (https:// or http://).

15.7.2

If you’re running GitLab CE/EE, upgrade to at least these versions!

How Should Developers Protect Against Unsafe Redirects?

Check and restrict the protocol before redirecting.

For Ruby (Rails)

# GOOD: Only allow http(s)
class RedirectController < ApplicationController
  def to_target
    target = params[:target]
    if safe_url?(target)
      redirect_to target
    else
      render plain: "Invalid redirect", status: :bad_request
    end
  end

  private

  def safe_url?(url)
    uri = URI.parse(url)
    uri.scheme.in?(["http", "https"])
  rescue URI::InvalidURIError
    false
  end
end

Never use user-supplied input as a URL destination without validating it.

References and Further Reading

- Official CVE: NIST CVE-2023-0042

GitLab Security Advisory (Jan 2023):

GitLab Security Release: 15.7.2, 15.6.4, and 15.5.7
- Project Discovery: Huntr
- Safe Redirects in Rails: OWASP Unvalidated Redirects

Conclusion

_CVE-2023-0042_ highlights the importance of validating all user input—especially before a redirect. If you host any GitLab Pages, check your version and upgrade immediately if affected. Developers should always enforce strict checks on URLs to avoid exposing users to arbitrary protocols and attacks.

Keep your users safe, validate those redirect URLs!

Did you find this helpful? Let us know how you secure your GitLab deployments—or share your questions about safe web redirects!

Timeline

Published on: 01/12/2023 04:15:00 UTC
Last modified on: 01/20/2023 20:04:00 UTC