Summary
NORA's token-management UI authenticates users but does not consistently verify administrator authorization before exposing or changing token records. A read-capable bearer token may reveal token metadata for other users, while a write-capable identity may revoke arbitrary tokens, including administrator and service credentials.
NORA's token-management UI authenticates users but does not consistently verify administrator authorization before exposing or changing token records. A read-capable bearer token may reveal token metadata for other users, while a write-capable identity may revoke arbitrary tokens, including administrator and service credentials.
Affected context
The issue occurs in NORA deployments where the token-management endpoints are enabled and authorization checks distinguish authentication from administrative privileges. The affected page and API can list token records across users, while revocation requests rely on write permission without requiring administrator rights or verifying token ownership. Read-only identities are not expected to have permission to submit revocation requests.
The issue occurs in NORA deployments where the token-management endpoints are enabled and authorization checks distinguish authentication from administrative privileges. The affected page and API can list token records across users, while revocation requests rely on write permission without requiring administrator rights or verifying token ownership. Read-only identities are not expected to have permission to submit revocation requests.
Exploit preconditions
- Attack surface: NORA's token-management UI and corresponding API endpoints
- Required access: A valid bearer token or authenticated OIDC identity with the relevant read or write capability
- Trigger point: Listing token records or submitting a token-revocation request
- Why exploitation is possible: Authentication is enforced, but authorization checks use write capability rather than administrator authorization, and token ownership is not validated
- Attack surface: NORA's token-management UI and corresponding API endpoints
- Required access: A valid bearer token or authenticated OIDC identity with the relevant read or write capability
- Trigger point: Listing token records or submitting a token-revocation request
- Why exploitation is possible: Authentication is enforced, but authorization checks use write capability rather than administrator authorization, and token ownership is not validated
Why this happens
The underlying flaw is a missing authorization decision at sensitive application boundaries. Although authentication middleware establishes the caller's identity, token listing and revocation do not consistently enforce the required administrator role or ownership relationship. This maps to CWE-862, Missing Authorization, because authenticated principals can reach operations whose permission checks are weaker than the sensitivity of the requested action.
The underlying flaw is a missing authorization decision at sensitive application boundaries. Although authentication middleware establishes the caller's identity, token listing and revocation do not consistently enforce the required administrator role or ownership relationship. This maps to CWE-862, Missing Authorization, because authenticated principals can reach operations whose permission checks are weaker than the sensitivity of the requested action.
Potential impact
- A read-capable user may discover the existence and metadata of other users' tokens
- An attacker may learn token owners, roles, descriptions, expiry times, and last-use information
- A write-capable identity may revoke administrator or service tokens
- Registry operations may be disrupted through unauthorized credential invalidation
- Administrators and services may require credential recovery or reauthentication
- A read-capable user may discover the existence and metadata of other users' tokens
- An attacker may learn token owners, roles, descriptions, expiry times, and last-use information
- A write-capable identity may revoke administrator or service tokens
- Registry operations may be disrupted through unauthorized credential invalidation
- Administrators and services may require credential recovery or reauthentication
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every sensitive
endpoint and applying the least privilege required for each token operation.
Common defensive patterns include:
- Require explicit administrator authorization for cross-user token listing and revocation
- Permit self-service operations only after verifying ownership of the target token
- Separate read, create, update, and revoke permissions rather than treating write access as sufficient
- Avoid exposing token metadata beyond what the requesting principal needs
- Apply centralized, fail-closed authorization policies consistently to UI and API routes
- Use short-lived credentials and narrowly scoped service identities where practical
- Record and review token-listing and revocation events for anomalous activity
Mitigation generally focuses on enforcing authorization at every sensitive
endpoint and applying the least privilege required for each token operation.
Common defensive patterns include:
- Require explicit administrator authorization for cross-user token listing and revocation
- Permit self-service operations only after verifying ownership of the target token
- Separate read, create, update, and revoke permissions rather than treating write access as sufficient
- Avoid exposing token metadata beyond what the requesting principal needs
- Apply centralized, fail-closed authorization policies consistently to UI and API routes
- Use short-lived credentials and narrowly scoped service identities where practical
- Record and review token-listing and revocation events for anomalous activity
How teams detect issues like this
Organizations can assess this class of issue through:
- Static analysis and code review rules that flag sensitive handlers guarded only by generic write permissions
- Tests that exercise authenticated users with different roles against every token-management operation
- Authorization-matrix testing to confirm cross-user access is denied by default
- Review of service methods for missing ownership checks before object retrieval, update, or deletion
- Runtime policy enforcement and audit monitoring for bulk token enumeration or unexpected revocations
- Automated security testing that compares endpoint behavior across read-only, write-capable, and administrator identities
Organizations can assess this class of issue through:
- Static analysis and code review rules that flag sensitive handlers guarded only by generic write permissions
- Tests that exercise authenticated users with different roles against every token-management operation
- Authorization-matrix testing to confirm cross-user access is denied by default
- Review of service methods for missing ownership checks before object retrieval, update, or deletion
- Runtime policy enforcement and audit monitoring for bulk token enumeration or unexpected revocations
- Automated security testing that compares endpoint behavior across read-only, write-capable, and administrator identities
