fix: prevent open redirect from whitelist subdomain suffix bypass

[hacktron-app-stg]

Vulnerability

IsValidRedirect in oauthproxy.go validates redirect targets against whitelistDomains. For a domain configured to allow subdomains via a leading dot (e.g. .example.com), the leading dot was trimmed into domainHostname (splitHostPort(strings.TrimLeft(domain, "."))) and the subdomain check used:

strings.HasPrefix(domain, ".") && strings.HasSuffix(redirectHostname, domainHostname)

Because domainHostname is the bare example.com, any hostname merely ending in that string matched — e.g. badexample.com is a suffix of example.com. An attacker could therefore pass ?rd=http://badexample.com and pass validation, yielding an open redirect.

Fix

Match the suffix against "." + domainHostname so only true subdomains (where the whitelisted domain is preceded by a dot) are accepted:

(redirectHostname == domainHostname) ||
    (strings.HasPrefix(domain, ".") && strings.HasSuffix(redirectHostname, "."+domainHostname))

Exact-domain redirects continue to be accepted through the unchanged redirectHostname == domainHostname branch, and legitimate subdomains like baz.bar.foo still end with .bar.foo. This mirrors the correct upstream behavior.

Verification

• Traced every case in TestIsValidRedirect against the new condition: exact-domain (bar.foo), subdomain (baz.bar.foo), and port variants all still evaluate as before; the new suffix restriction only rejects the bypass class (evilbar.foo no longer matches .bar.foo).
• Added a regression case invalidHTTPSubdomainSuffixBypass (http://evilbar.foo/redirect → expected false).
• Note: the Go toolchain is not available in the sandbox, so go test could not be executed; verification was done by static tracing and diff review.

---

Automated fix by Hacktron for finding: https://staging.hacktron.ai/i-need-an-org/findings/45d3a08d-d7e5-4b45-985b-b12f7ff7dbb8