Nezha Monitoring: OAuth2 Redirect URL — Host Header Injection

2. PoC

A conceptual attack (no Docker needed):

Scenario: OAuth2 provider has loose redirect URI validation
          (e.g., allows wildcard subdomain matching)

1. Attacker crafts a URL to the dashboard's OAuth2 login endpoint
   with a modified Host header:

   GET /api/v1/oauth2/github HTTP/1.1
   Host: attacker-controlled.com
   X-Forwarded-Proto: https

2. The dashboard responds with a redirect to:
   https://github.com/login/oauth/authorize?client_id=...&redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback&state=...

3. Victim clicks the attacker's link → authenticates with GitHub
   → GitHub redirects to https://attacker-controlled.com/api/v1/oauth2/callback?code=AUTH_CODE&state=...

4. Attacker captures the AUTH_CODE from their server logs

5. Attacker exchanges the code at the real dashboard's
   /api/v1/oauth2/callback endpoint (using the real Host header
   this time), binding the victim's OAuth identity to their
   dashboard account

Prerequisites for full exploit:

• The victim must click the attacker's crafted link
• The OAuth2 provider must accept the attacker's domain as a valid redirect URI (some providers accept https://*/* or allow wildcards; others are strict)

3. Impact

• Account takeover: an attacker who intercepts the OAuth2 authorization code can bind the victim's OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim's access level and permissions
• Privilege escalation: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment — access to all servers, credentials, and configuration
• Persistence: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)

The attack complexity is higher than typical Host header injection scenarios because it requires:

1. The Host header to reach the dashboard's handler unmodified (bypassing reverse proxy normalization)
2. The OAuth2 provider to have loose redirect URL validation
3. User interaction (the victim must authenticate)

However, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (Host header) for a security-critical URL that participates in the OAuth2 authorization code flow.

4. Remediation

1. Validate the Host header against a configured allowlist of known dashboard hostnames:

   func getRedirectURL(c *gin.Context) string {
       host := c.Request.Host
       if !singleton.Conf.IsAllowedHost(host) {
           host = singleton.Conf.DashboardBaseURL // fallback
       }
       // ...
   }
   

2. Pin the redirect URL to the configured dashboard URL from singleton.Conf instead of deriving it from the request Host header:

   func getRedirectURL(c *gin.Context) string {
       return singleton.Conf.DashboardBaseURL + "/api/v1/oauth2/callback"
   }
   

3. Remove Host header-based URL construction entirely — the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request

4. Add Host header validation middleware for all OAuth2-related endpoints as defense-in-depth