OpenID Session Token Persistence in Actual Finance App

Executive Summary

This vulnerability affects the Actual personal finance app in versions prior to 26.6.0 when using OpenID multi-user mode. When a user is disabled, the system only blocks future OpenID logins for that user identity. However, any existing session tokens for the disabled user remain valid because the session validation process does not check if the user is still enabled. This allows a disabled user to continue accessing authenticated server endpoints despite being disabled.

Useful 0 Not Useful 0

Impact Analysis

The vulnerability can allow a disabled user to maintain access to the application through existing session tokens. This means that even after disabling a user, that user could continue to perform actions and access sensitive data within the app, potentially leading to unauthorized access, data breaches, or misuse of the system.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, upgrade the Actual personal finance app to version 26.6.0 or later, where the issue is fixed.

Until the upgrade is applied, be aware that disabling a user in OpenID multi-user mode only blocks future logins but does not invalidate existing session tokens, so consider additional session management or token revocation strategies if possible.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows disabled users to retain access to authenticated server endpoints indefinitely due to sessions not being invalidated. This poses a high risk to confidentiality and integrity of sensitive data, including personal financial information.

Such unauthorized continued access can lead to non-compliance with data protection regulations like GDPR and HIPAA, which require strict access controls and timely revocation of access when a user is disabled or removed.

Failure to promptly invalidate sessions of disabled users may result in unauthorized data exposure or modification, violating principles of least privilege and data minimization mandated by these standards.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves disabled users retaining access through existing session tokens because the session validation does not check if the user is enabled. Detection would involve verifying whether sessions for disabled users are still accepted by the server.

Since the vulnerability is related to session validation logic on the server side, detection on the network or system could include monitoring for authenticated requests made by users who have been disabled in the system.

One approach is to audit the user status and active sessions in the application database or logs to identify if any disabled users have active sessions.

Specific commands depend on the environment and access to the Actual Budget application's backend or database. For example, querying the sessions table joined with the users table to find sessions where the user is disabled but the session is still active.

• Example SQL query to detect active sessions for disabled users (assuming access to the database):
• SELECT sessions.* FROM sessions JOIN users ON sessions.user_id = users.id WHERE users.enabled = FALSE AND sessions.expires > NOW();

Additionally, monitoring server logs for authenticated requests from disabled users or implementing application-level checks to log or alert on such activity can help detect exploitation.

No specific network commands or tools are provided in the available resources, so detection primarily relies on application or database-level inspection.

Useful 0 Not Useful 0