Summary
Nginx UI prior to 2.4.1 contains a login CSRF weakness in its Casdoor OAuth integration. Because the OAuth state value is predictable and is not bound to the browser session that initiated the flow, an unauthenticated attacker may cause a victim's browser to establish a Nginx UI session for an attacker-controlled identity.
Nginx UI prior to 2.4.1 contains a login CSRF weakness in its Casdoor OAuth integration. Because the OAuth state value is predictable and is not bound to the browser session that initiated the flow, an unauthenticated attacker may cause a victim's browser to establish a Nginx UI session for an attacker-controlled identity.
Affected context
The issue occurs in Nginx UI deployments that enable Casdoor authentication and use the affected OAuth authorization and callback handlers. Risk arises when the callback accepts a submitted authorization state without verifying that it matches a unique value previously issued to the initiating browser session.
The issue occurs in Nginx UI deployments that enable Casdoor authentication and use the affected OAuth authorization and callback handlers. Risk arises when the callback accepts a submitted authorization state without verifying that it matches a unique value previously issued to the initiating browser session.
Exploit preconditions
- Attack surface: Casdoor OAuth login and callback endpoints exposed through the Nginx UI web interface
- Required access: No authentication to Nginx UI is required; the attacker needs to influence a victim's browser and control or initiate an authorization flow
- Trigger point: Processing of the Casdoor OAuth callback
- Why exploitation is possible: The OAuth state is derived from a configured application name rather than a per-session value, and the callback does not verify that the returned state belongs to the initiating browser session
- Attack surface: Casdoor OAuth login and callback endpoints exposed through the Nginx UI web interface
- Required access: No authentication to Nginx UI is required; the attacker needs to influence a victim's browser and control or initiate an authorization flow
- Trigger point: Processing of the Casdoor OAuth callback
- Why exploitation is possible: The OAuth state is derived from a configured application name rather than a per-session value, and the callback does not verify that the returned state belongs to the initiating browser session
Why this happens
The vulnerability is caused by failing to bind an OAuth authorization response to the browser session that initiated the login request. Using a constant or predictable state value and omitting server-side comparison allows an attacker-controlled authorization response to be accepted in another user's browser.
This behavior maps primarily to CWE-352: Cross-Site Request Forgery, because a victim's authenticated session state can be changed through an unintended cross-site request. It also relates to CWE-287: Improper Authentication, because the callback does not adequately authenticate the relationship between the authorization request and response.
The vulnerability is caused by failing to bind an OAuth authorization response to the browser session that initiated the login request. Using a constant or predictable state value and omitting server-side comparison allows an attacker-controlled authorization response to be accepted in another user's browser.
This behavior maps primarily to CWE-352: Cross-Site Request Forgery, because a victim's authenticated session state can be changed through an unintended cross-site request. It also relates to CWE-287: Improper Authentication, because the callback does not adequately authenticate the relationship between the authorization request and response.
Potential impact
- A victim's browser may establish a Nginx UI session for an attacker-controlled identity
- Users may be misled about which account is active in the administrative interface
- Actions performed by the victim could be attributed to or visible to the attacker's account
- Downstream administrative or configuration changes could occur under the unintended session identity
- A victim's browser may establish a Nginx UI session for an attacker-controlled identity
- Users may be misled about which account is active in the administrative interface
- Actions performed by the victim could be attributed to or visible to the attacker's account
- Downstream administrative or configuration changes could occur under the unintended session identity
General mitigation guidance
Mitigation generally focuses on enforcing a strong, session-bound OAuth transaction.
Common defensive patterns include:
- Generate cryptographically random state values for every authorization request
- Store the expected state server-side or in a protected browser session
- Compare the callback state with the value associated with the initiating session before accepting the authorization code
- Invalidate state values after one use and enforce suitable expiration
- Validate redirect targets and OAuth issuer, client, and redirect-URI relationships
- Apply secure cookie attributes and least-privilege permissions to authenticated sessions
- Prefer authentication libraries and framework integrations that provide state and nonce validation by default
Mitigation generally focuses on enforcing a strong, session-bound OAuth transaction.
Common defensive patterns include:
- Generate cryptographically random state values for every authorization request
- Store the expected state server-side or in a protected browser session
- Compare the callback state with the value associated with the initiating session before accepting the authorization code
- Invalidate state values after one use and enforce suitable expiration
- Validate redirect targets and OAuth issuer, client, and redirect-URI relationships
- Apply secure cookie attributes and least-privilege permissions to authenticated sessions
- Prefer authentication libraries and framework integrations that provide state and nonce validation by default
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for constant, user-controlled, or missing OAuth state validation
- Review of authorization handlers to confirm state is generated per request and bound to a browser session
- Tests that replay an authorization response in a different session and verify that it is rejected
- Monitoring for unusual OAuth callback activity, repeated state values, and sessions created without a matching login initiation
- Policy enforcement requiring OAuth libraries to validate state, nonce, issuer, and redirect URI values
- Automated security review tools that identify missing CSRF protections or unsafe OAuth callback patterns
Organizations can look for this class of issue through:
- Static analysis and code review checks for constant, user-controlled, or missing OAuth state validation
- Review of authorization handlers to confirm state is generated per request and bound to a browser session
- Tests that replay an authorization response in a different session and verify that it is rejected
- Monitoring for unusual OAuth callback activity, repeated state values, and sessions created without a matching login initiation
- Policy enforcement requiring OAuth libraries to validate state, nonce, issuer, and redirect URI values
- Automated security review tools that identify missing CSRF protections or unsafe OAuth callback patterns
