Summary
bbs-go's Google One Tap login endpoint does not verify that a Google-signed ID token was issued for the application's own OAuth client. An attacker using a token from another OAuth client may therefore obtain an authenticated session as a victim whose identity is linked to a bbs-go account.
bbs-go's Google One Tap login endpoint does not verify that a Google-signed ID token was issued for the application's own OAuth client. An attacker using a token from another OAuth client may therefore obtain an authenticated session as a victim whose identity is linked to a bbs-go account.
Affected context
This vulnerability occurs in deployments using the /api/login/google_one_tap endpoint for Google-based authentication. It becomes risky when the application accepts Google ID tokens without validating the aud claim against a trusted, application-specific OAuth client identifier, allowing tokens issued for unrelated clients to reach the account-login flow.
This vulnerability occurs in deployments using the /api/login/google_one_tap endpoint for Google-based authentication. It becomes risky when the application accepts Google ID tokens without validating the aud claim against a trusted, application-specific OAuth client identifier, allowing tokens issued for unrelated clients to reach the account-login flow.
Exploit preconditions
- Attack surface: Public Google One Tap authentication endpoint
- Required access: Ability to submit a Google-signed ID token to the endpoint; an attacker may operate or access a separate Google OAuth client
- Trigger point: Processing of the submitted token during login
- Why exploitation is possible: The application authenticates the token issuer and identity without confirming that the token audience matches the intended bbs-go OAuth client
- Attack surface: Public Google One Tap authentication endpoint
- Required access: Ability to submit a Google-signed ID token to the endpoint; an attacker may operate or access a separate Google OAuth client
- Trigger point: Processing of the submitted token during login
- Why exploitation is possible: The application authenticates the token issuer and identity without confirming that the token audience matches the intended bbs-go OAuth client
Why this happens
The underlying bug is incomplete validation of an externally issued authentication assertion. The login flow accepts a valid Google ID token but omits validation of its aud claim, which identifies the OAuth client for which the token was issued. This maps to CWE-287: Improper Authentication, because the application treats an assertion intended for another client as sufficient proof for its own authentication context.
The underlying bug is incomplete validation of an externally issued authentication assertion. The login flow accepts a valid Google ID token but omits validation of its aud claim, which identifies the OAuth client for which the token was issued. This maps to CWE-287: Improper Authentication, because the application treats an assertion intended for another client as sufficient proof for its own authentication context.
Potential impact
- Attackers may obtain authenticated sessions as other users
- User accounts linked to Google identities could be taken over
- Unauthorized access to private posts, messages, profiles, or administrative functions may occur
- Attackers could modify account data or perform actions under a victim's identity
- Compromised accounts could support further abuse or lateral access
- Attackers may obtain authenticated sessions as other users
- User accounts linked to Google identities could be taken over
- Unauthorized access to private posts, messages, profiles, or administrative functions may occur
- Attackers could modify account data or perform actions under a victim's identity
- Compromised accounts could support further abuse or lateral access
General mitigation guidance
Mitigation typically focuses on validating every security-relevant property of third-party identity assertions before creating a session.
Common defensive patterns include:
- Restricting accepted ID tokens to an explicit allowlist of application-owned OAuth client identifiers
- Validating the issuer, audience, signature, expiration, nonce, and relevant subject claims
- Using provider-supported libraries and secure-by-default verification APIs rather than manually trusting decoded claims
- Binding login state and nonce values to the initiating browser session where applicable
- Avoiding account matching based solely on unverified or insufficiently scoped identity attributes
- Applying least privilege to authenticated sessions and requiring stronger verification for sensitive account changes
- Treating tokens issued for other applications as invalid, even when their signatures are valid
Mitigation typically focuses on validating every security-relevant property of third-party identity assertions before creating a session.
Common defensive patterns include:
- Restricting accepted ID tokens to an explicit allowlist of application-owned OAuth client identifiers
- Validating the issuer, audience, signature, expiration, nonce, and relevant subject claims
- Using provider-supported libraries and secure-by-default verification APIs rather than manually trusting decoded claims
- Binding login state and nonce values to the initiating browser session where applicable
- Avoiding account matching based solely on unverified or insufficiently scoped identity attributes
- Applying least privilege to authenticated sessions and requiring stronger verification for sensitive account changes
- Treating tokens issued for other applications as invalid, even when their signatures are valid
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and code review rules that flag decoded token claims used without audience validation
- Review of OAuth and OpenID Connect flows for issuer, audience, nonce, expiration, and signature checks
- Tests that submit valid tokens issued for unrelated OAuth clients and verify that authentication is rejected
- Runtime monitoring for login tokens whose audience does not match the configured application client
- Policy enforcement requiring centralized, standards-compliant identity-token verification
- Automated security review tools that identify incomplete JWT or OpenID Connect validation
Organizations can detect this class of issue through:
- Static analysis and code review rules that flag decoded token claims used without audience validation
- Review of OAuth and OpenID Connect flows for issuer, audience, nonce, expiration, and signature checks
- Tests that submit valid tokens issued for unrelated OAuth clients and verify that authentication is rejected
- Runtime monitoring for login tokens whose audience does not match the configured application client
- Policy enforcement requiring centralized, standards-compliant identity-token verification
- Automated security review tools that identify incomplete JWT or OpenID Connect validation
