Rack session gets restored after deletion
SummaryWhen using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.Details[Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.ImpactWhen using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.MitigationUpdate to the latest version of `rack-session`, orEnsure your application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse, orImplement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.RelatedThis code was previously part of `rack` in Rack < 3, see <https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g> for the equivalent advisory in `rack` (affecting Rack < 3 only).