Vulnerability GHSA-23wf-92cp-8pcj

Summary

The c.Scheme() method in Echo (context.go:162-181) trusts the X-Forwarded-Proto, X-Forwarded-Protocol, and X-Url-Scheme request headers without validating that the value is http or https. The WWWRedirect() and NonWWWRedirect() middlewares use this unsanitized scheme to construct redirect URLs, allowing an attacker to inject arbitrary URI schemes into the Location response header.

Affected Components

• context.go:162-181 - Scheme() method returns attacker-controlled value verbatim
• middleware/redirect.go:172-184 - redirectWWW/redirectNonWWW use unsanitized scheme

Proof of Concept

GET /path HTTP/1.1
Host: example.com
X-Forwarded-Proto: javascript

Response:
HTTP/1.1 301 Moved Permanently
Location: javascript://www.example.com/path

Confirmed injectable schemes: javascript, data, vbscript, file, ftp, ssh, telnet, gopher.

Only WWWRedirect() and NonWWWRedirect() (and WithConfig variants) are affected. HTTPSRedirect, HTTPSWWWRedirect, HTTPSNonWWWRedirect are NOT affected (they hardcode https://).

Impact

• Open redirect to arbitrary scheme URLs when app is not behind a proxy that strips X-Forwarded-Proto
• Cache poisoning when behind a CDN that caches redirect responses keyed by path
• file:// scheme injection could trigger file access in some browser configurations

Suggested Fix

Whitelist scheme in c.Scheme() to only return http or https:

func (c *Context) Scheme() string {
    if c.IsTLS() {
        return "https"
    }
    if scheme := c.request.Header.Get(HeaderXForwardedProto); scheme != "" {
        scheme = strings.ToLower(strings.TrimSpace(scheme))
        if scheme == "https" {
            return "https"
        }
    }
    return "http"
}

Disclosure

Source code review, manually verified with actual HTTP server. Tested on Echo v5.0.4 (latest master).

Patches

Fixed in github.com/labstack/echo/v5 v5.1.1 and github.com/labstack/echo/v4 v4.15.2. Context.Scheme() now accepts only http, https, ws or wss from the X-Forwarded-Proto, X-Forwarded-Protocol and X-Url-Scheme headers, and falls back to http for any other value (#2953).

Workarounds

Upgrade to a patched version. If you cannot upgrade, have your edge proxy overwrite or remove the X-Forwarded-Proto, X-Forwarded-Protocol and X-Url-Scheme request headers.