This feels less like a framework bug for me than an app bug -- an impressively common app bug, I'll grant you, but an app bug nonetheless. Rails doesn't ship with user management. It's pretty upfront about that, and the docs tell you to roll your own since it is easy, and the community will tell you to use Devise since that will save you time since you'll be doing repetitive work for substantially all apps otherwise.
The typical way beginning Rails developers (including me, on my first Rails apps) would implement logins is stuffing the user ID in session[:user_id] and setting the currently logged in user to that when it is both present and in the DB.
It is true that this approach will make sessions replayable. It will also:
1) Make it impossible to reliably expire session, since the user's browser is not under your control and may treat the expiration date as advisory only.
2) Make it impossible to forcibly expire session, which you'll want to do in event of a user changing or resetting their password, changing their username/email address, etc. (Generic security advice for all web apps, by the way. Otherwise compromise of user accounts, via losing password, XSS, or what have you, is impossible to reverse.)
3) Makes it impossible to implement Sign Me Out Of All Devices, which is a very desirable capability to have for many applications. For example, if you have a more-important-than-cat-videos app, somebody losing their phone should probably not result in their account on your service being irrevocably compromised. You could provide a Dropbox-esque UI to manage their state across multiple devices or, in a pinch, just say "If you hit the log out button on any device, we log you out of all devices."
4) The simplest possible Rails login system is facially non-compliant with a number of security regimes you might be under, including HIPAA among others.
n.b. Switching to ActiveRecordStore doesn't by itself solve anything but #1. You do need app-side logic.
I actually regard this as a framework bug. Rails has been promoting the Cookie-Storage for at least two major releases. There's a couple of upsides to cookie storage that make it appealing, but the downside is the given lack of control. Some of those points you mention could be tackled even with cookie storage, but not all of them:
2) in the case of a compromise you can change the app secret. That's a pretty big sledgehammer and will log out all users from the app, but it will reliable smash that fly.
1) could be tackled the way gitbub proposed: just include the expiry date in the signed cookie. Discard any cookie that's past expiry.
3) could be tackled by using some sort of per-user cookie secret. That however would require a storage again and then you could as well store the whole session in said storage. Not much to win here.
I also wondered whether Devise handled this issue and looked at the source. Devise doesn't address this issue. It relies on warden underneath and serializes the user into the session without any sort of expiry (https://github.com/plataformatec/devise/blob/master/lib/devi...). There are a lot of options for remediation, though, like overriding the aforementioned serialization hash to attach an expiry, or setting an expiry in a separate key in the session.
The typical way beginning Rails developers (including me, on my first Rails apps) would implement logins is stuffing the user ID in session[:user_id] and setting the currently logged in user to that when it is both present and in the DB.
It is true that this approach will make sessions replayable. It will also:
1) Make it impossible to reliably expire session, since the user's browser is not under your control and may treat the expiration date as advisory only.
2) Make it impossible to forcibly expire session, which you'll want to do in event of a user changing or resetting their password, changing their username/email address, etc. (Generic security advice for all web apps, by the way. Otherwise compromise of user accounts, via losing password, XSS, or what have you, is impossible to reverse.)
3) Makes it impossible to implement Sign Me Out Of All Devices, which is a very desirable capability to have for many applications. For example, if you have a more-important-than-cat-videos app, somebody losing their phone should probably not result in their account on your service being irrevocably compromised. You could provide a Dropbox-esque UI to manage their state across multiple devices or, in a pinch, just say "If you hit the log out button on any device, we log you out of all devices."
4) The simplest possible Rails login system is facially non-compliant with a number of security regimes you might be under, including HIPAA among others.
n.b. Switching to ActiveRecordStore doesn't by itself solve anything but #1. You do need app-side logic.