CVE-2023-45289: HTTP Client Header Disclosure Vulnerability

CVE-2023-45289 Overview

CVE-2023-45289 is a security vulnerability in the Go programming language's http.Client that involves improper handling of sensitive HTTP headers during redirect operations. When an HTTP client follows a redirect to a domain that is not a subdomain match or exact match of the initial domain, sensitive headers such as Authorization or Cookie should not be forwarded. However, a maliciously crafted HTTP redirect could cause these sensitive headers to be unexpectedly forwarded to unauthorized domains, potentially exposing authentication credentials or session tokens.

Critical Impact

Authentication credentials and session cookies may be leaked to malicious third-party domains through crafted HTTP redirects, enabling credential theft and session hijacking attacks.

Affected Products

• Go programming language net/http package
• Applications using Go's http.Client for HTTP requests with redirects
• NetApp products (per security advisory)

Discovery Timeline

• 2024-03-05 - CVE CVE-2023-45289 published to NVD
• 2024-03-08 - Public disclosure via OpenWall OSS-Security mailing list
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-45289

Vulnerability Analysis

This vulnerability exists in Go's HTTP client redirect handling logic within the net/http package. The core issue involves the domain matching algorithm that determines when sensitive headers should be stripped during cross-domain redirects.

Under normal circumstances, Go's http.Client is designed to protect users by not forwarding sensitive headers like Authorization and Cookie when redirected to a different domain. For example, a redirect from foo.com to www.foo.com (a subdomain) would preserve these headers, while a redirect to bar.com (an unrelated domain) would strip them.

However, the vulnerability allows a maliciously crafted redirect URL to bypass this domain matching logic, causing sensitive headers to be forwarded to domains where they should not be sent. This creates a significant information disclosure risk where attackers controlling a malicious server could harvest authentication tokens, API keys, or session cookies from unsuspecting clients.

Root Cause

The root cause lies in the domain comparison logic used to determine subdomain relationships during redirect processing. The matching algorithm fails to properly validate certain edge cases in domain name comparisons, allowing an attacker to craft redirect URLs that appear to match the subdomain criteria when they actually point to different domains entirely.

Attack Vector

The attack requires a network-based approach where an attacker can influence HTTP redirects. The exploitation scenario involves:

1. An attacker sets up a malicious server that issues specially crafted redirect responses
2. A victim's Go application makes an HTTP request with sensitive headers to a legitimate or attacker-controlled initial endpoint
3. The server responds with a redirect to an attacker-controlled domain using a crafted URL that bypasses the domain matching check
4. The Go http.Client incorrectly determines the redirect target is a valid subdomain and forwards the sensitive Authorization or Cookie headers
5. The attacker's server captures the leaked credentials

The attack is relatively straightforward to execute against vulnerable applications, requiring low privileges and no user interaction once the initial request is made.

Detection Methods for CVE-2023-45289

Indicators of Compromise

• Unexpected HTTP requests containing Authorization or Cookie headers to untrusted external domains
• Application logs showing redirects to suspicious or unfamiliar domains
• Authentication tokens appearing in third-party server logs
• Unusual session activity following HTTP redirect chains

Detection Strategies

• Implement network monitoring to detect HTTP redirect chains that terminate at unexpected domains
• Deploy application logging that captures full redirect chains including destination domains
• Utilize SentinelOne's behavioral analysis to identify applications leaking credentials through abnormal HTTP patterns
• Monitor for Go applications making authenticated requests that follow multi-hop redirects

Monitoring Recommendations

• Enable verbose HTTP client logging in Go applications to track redirect behavior
• Configure intrusion detection systems to alert on sensitive header values appearing in traffic to non-whitelisted domains
• Implement SentinelOne endpoint protection to monitor process network behavior for credential leakage patterns
• Review application traffic patterns for unexpected cross-domain redirects involving authenticated sessions

How to Mitigate CVE-2023-45289

Immediate Actions Required

• Update Go installations to the patched version that addresses this vulnerability
• Review and update all applications compiled with vulnerable Go versions
• Implement explicit redirect validation in application code using custom CheckRedirect functions
• Audit existing applications for sensitive header usage in HTTP client operations

Patch Information

The Go team has released patches to address this vulnerability. The fix is documented in the Go.dev Code Review and tracked in the Go.dev Issue Tracker. Organizations should update to the patched Go version and recompile affected applications. The official vulnerability report is available at the Go.dev Vulnerability Report.

NetApp has also released an advisory for affected products, available at the NetApp Security Advisory.

Workarounds

• Implement a custom CheckRedirect function on http.Client that validates redirect targets and strips sensitive headers manually
• Configure applications to disable automatic redirect following and handle redirects explicitly with header sanitization
• Use application-level firewalls to block redirects to untrusted domains
• Consider proxying HTTP requests through a service that enforces strict redirect policies

# Example: Update Go and rebuild applications
# Check current Go version
go version

# Update Go to latest patched version (check go.dev for current release)
# After updating, rebuild all affected applications
go build -a ./...

# Verify the new binary is using updated runtime
go version -m ./your-application