Client side sessions should not allow unencrypted storage

Vulnerability

In Ratpack versions prior to 1.9.0, the default configuration of client side sessions stores session data as signed but unencrypted cookie values [1], [2], [3]. This means any sensitive data placed into the session can be read by any party with access to the cookies. The vulnerability is present in versions before 1.9.0, where the session secret was not randomly generated [1]. Version 1.9.0 introduced a securely randomly generated signing key [1], [3].

Exploitation

Exploitation requires two conditions: (1) an application must store sensitive data in the client-side session, and (2) an attacker must be able to read the session cookie [2], [3]. The attacker can obtain the cookie through means such as a cross-site scripting (XSS) vulnerability on the same site, or if the cookies are not configured with the HttpOnly flag [2], [3]. No authentication or network position is specified beyond access to the cookie.

Impact

If successfully exploited, the attacker gains read access to the sensitive data stored in the session cookie [2], [3]. This could include user credentials, personal information, or other confidential data. The impact is limited to information disclosure; the attacker does not gain code execution or write access through this vulnerability alone.

Mitigation

As of Ratpack 1.9.0, the default configuration uses a securely randomly generated signing key, which mitigates the issue [1], [2], [3]. This means sessions will not survive application restarts, but that was already the case with the previous random signing key [3]. As a workaround for older versions, users can supply an encryption key explicitly, as recommended in the documentation [2], [3].