Project

General

Profile

Forums » Open discussion »

Open Vulnerability of Session Replay in Redmine 6.1.2

Added by KUNTAL MONDAL 3 days ago

  • VULNERABILITY NAME
    Session Replay
  • DESCRIPTION
    Web applications that do not ensure that all session tokens (e.g.: cookies) are properly destroyed or made unusable, are prone to session replay where an attacker steals the session identifier by sniffing and replays these session tokens to "resurrect" the session of a legitimate user and virtually impersonate him/her.
  • OBSERVATION
    It was possible to sniff the session of the legitimate user and gain access of the application by replaying the sniffed user session.
  • IMPACT
    An attacker may exploit this flaw by sniffing the session of an authenticated user and can replay the same to gain access to the restricted/authenticated pages of the application
  • RISK RATING
    High

Our ISG (Internet Security Team) has identified the above vulnerability. Could someone please assist or provide guidance on how to address this issue?


Replies (1)

RE: Open Vulnerability of Session Replay in Redmine 6.1.2 - Added by Holger Just 1 day ago

Redmine stores the session data in an encrypted and signed cookie. It further ties the validity of a session to a token which is stored in the database on the server. When logging out or performing sensitive actions (such as changing your password), these tokens are deleted, marking the respective sessions as invalid.

Now, if an attacker gains access to a cookie of a valid session (that is: with an associated database token), they will be able to use this session with the permissions of the associated user. This however is true for about all web applications which use cookies for session identification (i.e., all of them).

As such, it is important to protect this session cookie. Usually, this is done by using and enforcing HTTPS for all access and setting appropriate HTTP headers such as Strict-Transport-Security. This prevents an attacker from "sniffing" a session in the first place. Furthermore, you Administrators can restrict the maximum overall age of a session as well as an inactivity timeout in Administration -> Settings -> Authentication. Depending on your organisation's security requirements, appropriate settings here can help balance security needs (when restricting these timeouts) against better usability (when not arbitrarily expiring sessions).

As such, what you describe here is not a security vulnerability in Redmine itself. If you are not using HTTPS however, you should reconfigure your webserver to use HTTPS.

In the future however, if you have more details or have found an actual vulnerability in Redmine, please make sure to send an email to security(at)redmine.org instead of publicly posting here. That way, we can assess the issue and a coordinate required remediation steps in private which helps protect all users of Redmine.

    (1-1/1)