There’s a possible information leak / session hijack vulnerability in Rack.
Attackers may be able to find and hijack sessions by using timing attacks targeting the session id. Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session.
The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison.
The session id stored in a cookie is the same id that is used when querying the backing session storage engine. Most storage mechanisms (for example a database) use some sort of indexing in order to speed up the lookup of that id. By carefully timing requests and session lookup failures, an attacker may be able to perform a timing attack to determine an existing session id and hijack that session.
|Access Vector||Access Complexity||Authentication||Confidentiality Impact||Integrity Impact||Availability Impact|
~> 1.6.12 >= 2.0.8