Skip to content

fix(auth0-express): reject userinfo (@) in inferred base URL host - #45

Open
frederikprijck wants to merge 1 commit into
mainfrom
fix/reject-userinfo-in-inferred-host
Open

fix(auth0-express): reject userinfo (@) in inferred base URL host#45
frederikprijck wants to merge 1 commit into
mainfrom
fix/reject-userinfo-in-inferred-host

Conversation

@frederikprijck

Copy link
Copy Markdown
Member

Summary

Hardens dynamic base-URL inference against Host-header userinfo injection, flagged in a security review.

When appBaseUrl is undefined (dynamic mode), inferBaseUrlFromRequest builds the base URL from the Host (or trusted X-Forwarded-Host) header. A header like legitimate.com@evil.com is parsed by the URL constructor as userinfo legitimate.com with origin evil.com. Since the inferred value feeds the origin checks in createRouteUrl / toSafeRedirect, a smuggled userinfo component could confuse origin determination.

This change rejects any inferred host containing @, returning null (which surfaces as an InvalidConfigurationError in resolveAppBaseUrl).

Context / severity

This is defense-in-depth, not a confirmed exploitable open redirect:

  • In dynamic mode, the Host header is already trusted by design, and the redirect_uri is derived from the same inferred base URL — so Auth0's registered-callback-URL validation independently rejects the poisoned URI. The @ trick grants no extra capability over simply sending Host: evil.com.
  • In allow-list mode, the inferred origin is matched against the configured list and the clean allow-list entry is returned, so the attacker string is never used.

Still, rejecting @ is cheap and correct — the existing spec test already earmarked this as future hardening.

Changes

  • app-base-url.ts: reject inferred hosts containing @.
  • app-base-url.spec.ts: flip the previously-documented "current behaviour" test to assert null, and add an X-Forwarded-Host case.

Testing

  • vitest run — 207 passed
  • npm run lint — clean

🤖 Generated with Claude Code

A Host or X-Forwarded-Host header like `legitimate.com@evil.com` is
parsed by the URL constructor as userinfo `legitimate.com` with origin
`evil.com`. In dynamic (undefined) base-URL mode this value is trusted
directly, and previously nothing rejected the userinfo, letting an
attacker smuggle an attacker-controlled origin past the origin checks
that consume the inferred base URL.

Reject any inferred host containing `@`. Hardens the origin checks in
`createRouteUrl`/`toSafeRedirect` as defense-in-depth.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant