Default client side session signing key is highly predictable

Vulnerability

Ratpack versions prior to 1.9.0 have a vulnerability in the client-side session module, where the default signing key for session cookies is derived from the application startup time (System.currentTimeMillis() / 10000) [1][3]. The signing key is set in ClientSideSessionConfig.java as the variable secretToken [2]. This weak key generation means that if encryption is not also used (recommended but not enabled by default), an attacker who can determine the application startup time can forge or tamper with session data [1][3].

Exploitation

An attacker needs the ability to determine the application startup time of the target Ratpack application (for example, through information leakage or by observing response headers) and the ability to write cookies to a victim's browser [1][3]. By calculating the signing key from the startup time and forging a valid session cookie, the attacker can modify session data without needing further authentication [3].

Impact

A successful attacker can tamper with client-side session data, potentially impersonating other users or gaining unauthorized privileges [1][3]. The confidentiality and integrity of session information are compromised, though encryption (not enabled by default) would mitigate the impact. The default configuration also causes all sessions to be invalidated on application restart, making it unsuitable for production [3].

Mitigation

The vulnerability is fixed in Ratpack version 1.9.0, which uses a securely randomly generated signing key at application startup [1][3]. As a workaround for earlier versions, users should supply an alternative signing key as per the documentation's recommendation [1][3]. No other workarounds are provided in the available references.