You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2020. It is now read-only.
The SessionsController#destroy action uses logout_killing_session! to log the user out. This effectively does 2 things:
set the session's user_id to nil
reset the session, which generates a new session id
The problem is that the changes made in step (1) are never persisted to the database. This allows anyone with access to the previous session id to access restricted pages without supplying any credentials.
I am not sure of the proper patch here, as Rails's middleware-based session handling loads and persists the session at a different layer. So it's awkward to "flush" the session to the database from inside the request cycle.
My workaround was a bit of a hack -- I just delete the session since I don't care about keeping it around:
Here is a blueprint of a test to replicate the behavior:
test "invalidates sessions after user has logged out" do
user = Factory(:user)
get login_url
post_via_redirect create_session_url, :email => user.email, :password => user.password
session_id_before_logout = cookies[SESSION_ID_COOKIE_KEY]
get_via_redirect logout_url
open_session do |attacker_session|
attacker_session.cookies[SESSION_ID_COOKIE_KEY] = session_id_before_logout
attacker_session.get some_url_in_your_app
attacker_session.assert_redirected_to login_url
end
end
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The SessionsController#destroy action uses logout_killing_session! to log the user out. This effectively does 2 things:
The problem is that the changes made in step (1) are never persisted to the database. This allows anyone with access to the previous session id to access restricted pages without supplying any credentials.
I am not sure of the proper patch here, as Rails's middleware-based session handling loads and persists the session at a different layer. So it's awkward to "flush" the session to the database from inside the request cycle.
My workaround was a bit of a hack -- I just delete the session since I don't care about keeping it around:
Here is a blueprint of a test to replicate the behavior:
The text was updated successfully, but these errors were encountered: