Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The client side session module uses the application startup time as the signing key by default. This means that if an attacker can determine this time, and if encryption is not also used (which is recommended, but is not on by default), the session data could be tampered with by someone with the ability to write cookies. The default configuration is unsuitable for production use as an application restart renders all sessions invalid and is not multi-host compatible, but its use is not actively prevented. Vulnerability Location https://github.com/ratpack/ratpack/blob/29434f7ac6fd4b36a4495429b70f4c8163100332/ratpack-session/src/main/java/ratpack/session/clientside/ClientSideSessionConfig.java#L29 Patches As of Ratpack 1.9.0 the default value is a securely randomly generated value, generated at application startup time. Workarounds Supply an alternative signing key, as per the documentation's recommendation.
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The default configuration of client side sessions results in unencrypted, but signed, data being set as cookie values. This means that if something sensitive goes into the session, it could be read by something with access to the cookies. Note: the documentation does point this out and encourage users to add an encryption key, but it is not mandatory. For this to be a vulnerability, some kind of sensitive data would need to be stored in the session and the session cookie would have to leak. For example, the cookies are not configured with httpOnly and an adjacent XSS vulnerability within the site allowed capture of the cookies. The proposed change is to change the default behaviour to use a randomly generated encryption key. This would mean that sessions do not survive app restarts, but this is already the behaviour given the random signing key. Patches As of version 1.9.0, a securely randomly generated signing key is used. Workarounds Supply an encryption key, as per the…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ratpack versions before 1.6.1 generate a session ID using a cryptographically weak PRNG in the JDK's ThreadLocalRandom. This means that if an attacker can determine a small window for the server start time and obtain a session ID value, they can theoretically determine the sequence of session IDs.
Recommended action: Upgrade to 1.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.