Live data from Hacker News

Logout is broken by default in Ruby on Rails Web applications

maverickblogging.com

41–50 of 59 posts

Re: Logout is broken by default in Ruby on Rails Web applications

#41
post #38

Misleading. It's not a problem of CookieStore or Rails, it's the problem of HTTP. Changing session store to a database or memory store won't fix it: a session id is still required on the client side, then your session is still hijacked because the attacker still gets the session id. You may want to make the session id change after each request, then you are re-inventing TCP and ruining user experience. If the attacke…

  Changing session store to a database or memory store won't 
  fix it: a session id is still required on the client side, 
  then your session is still hijacked because the attacker 
  still gets the session id.
The bug specifically addresses logging out.

When you store a record of the session on the server side (with the session ID you mention), you clear that session record during logout; the session is now gone, and cookie isn't valid anymore.

(With the cookie-only approach, the server will continue to accept a cookie that you wanted to have cleared.)

Re: Logout is broken by default in Ruby on Rails Web applications

#42
post #35

Earlier quoted context omitted.

Using a server based session storage is simple as long as your whole app lives in one datacenter and all frontend hosts can reach said server. Once you have app servers in multiple datacenters (e.g. for geo loadbalancing) and want to provide a seamless login no matter which server the user ends up on server based session storage just gets a lot harder. (Apart from having to handle a massive write load which used to c…

Redis is an ideal data store for this kind of thing, will be doubly so once we have Redis Cluster. But still, if your frontend hosts can't reach your database, you have far bigger problems than your sessions not working.

There's a whole class of applications that can happily serve data that slightly stale, so they can use any kind of replication/cluster to make data available on multiple datacenters, even if that makes for a little lag. Session data however must be instant, so that requires a very fast and stable replication, making the problem much harder. Redis is particularly unsuited to serve such data since it's single-master replication only. It's totally fine in a single datacenter, but fails once you move out. Redis cluster may or may not be a solution, but it's not here yet anyways.

Re: Logout is broken by default in Ruby on Rails Web applications

#43

Earlier quoted context omitted.

Very sloppy it wasn't encrypted from day 1 imo.

Day 1 was eight years ago. Care to tell which popular web frameworks did that then?

most popular web frameworks don't put data in the cookie, signed or not. yes it introduces different problems, but avoids this one.

Re: Logout is broken by default in Ruby on Rails Web applications

#44
post #25

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.…

So using Devise gets around this issue right?

If you use Devise make sure to read this, too:

http://stackoverflow.com/questions/11281141/after-logout-if-...

(I was quite surprised a long while back :-)

Re: Logout is broken by default in Ruby on Rails Web applications

#45

Earlier quoted context omitted.

So using Devise gets around this issue right?

If you use Devise make sure to read this, too: http://stackoverflow.com/questions/11281141/after-logout-if-... (I was quite surprised a long while back :-)

This is interesting...still doesn't answer my question though :)

Re: Logout is broken by default in Ruby on Rails Web applications

#46

Earlier quoted context omitted.

If you use Devise make sure to read this, too: http://stackoverflow.com/questions/11281141/after-logout-if-... (I was quite surprised a long while back :-)

This is interesting...still doesn't answer my question though :)

Sorry! I didn't mean to imply that it was answering your question.

I thought bringing that information was still fairly useful, potentially.

Re: Logout is broken by default in Ruby on Rails Web applications

#47
post #38

Misleading. It's not a problem of CookieStore or Rails, it's the problem of HTTP. Changing session store to a database or memory store won't fix it: a session id is still required on the client side, then your session is still hijacked because the attacker still gets the session id. You may want to make the session id change after each request, then you are re-inventing TCP and ruining user experience. If the attacke…

Changing session store to a database or memory store won't fix it: a session id is still required on the client side, then your session is still hijacked because the attacker still gets the session id. The bug specifically addresses logging out. When you store a record of the session on the server side (with the session ID you mention), you clear that session record during logout; the session is now gone, and cookie…

When I click log out, I know I'm logging out on this browser but not other browsers. I usually want to keep my session on other devices... But you can still achieve "log me out on every devices" with CookieStore, it doesn't limit you from storing and checking things on the server-side.

Re: Logout is broken by default in Ruby on Rails Web applications

#48
post #47

Earlier quoted context omitted.

Changing session store to a database or memory store won't fix it: a session id is still required on the client side, then your session is still hijacked because the attacker still gets the session id. The bug specifically addresses logging out. When you store a record of the session on the server side (with the session ID you mention), you clear that session record during logout; the session is now gone, and cookie…

When I click log out, I know I'm logging out on this browser but not other browsers. I usually want to keep my session on other devices... But you can still achieve "log me out on every devices" with CookieStore, it doesn't limit you from storing and checking things on the server-side.

  When I click log out, I know I'm logging out on this
  browser but not other browsers.
Different browsers get different sessions.

  ... it doesn't limit you from storing and checking
  things on the server-side.
Correct, but you basically end up reimplementing parts of ActiveRecord::SessionStore anyway.

Re: Logout is broken by default in Ruby on Rails Web applications

#49
post #3

I sincerely hope that nobody was using the CookieStore in deployment. I think everybody should know by now that cookies are not safe or secure storage for data.

What your forgetting is the reason people use frameworks such as Rails - so they don't have to care about these types of details. I agree that simply storing everything in the cookie is wrong, and Rails should never have been doing this - hell, even CodeIgniter (PHP) has DB based sessions. But most Rails devs (myself included) are just about getting shit done, we don't know everything that's going on under the bonnet…

> But most Rails devs (myself included) are just about getting shit done, we don't know everything that's going on under the bonnet, and we don't want to.

I love getting shit done.

It's my job as a professional to know everything that's going on "under the bonnet."

I'm still learning.

But it's my job to try.

Re: Logout is broken by default in Ruby on Rails Web applications

#50
post #5

This is a very common problem in a lot of signed cookie based session stores. Some frameworks get it right, some don't. The best remediation is to include an expire timestamp within the content of the signed cookie and to check this on the server - you can't rely on the client deleting the cookie ( never trust the client). The guys at GitHub fixed this particular issue in their rails stack, and submitted a pull reque…

The solution I use in my own application is for each cookie that gets set to be a distinct, random shared secret that is mirrored in a database table. The shared secret is the combination of a near-random string of bytes generated by a hash of numerous things, plus a unique ID generated upon insert into the database table. The secret survives in the table until the user chooses to sign out, or until the cookie expire…

>..random shared secret that is mirrored in a database table.

Isn't the point of using a cookiestore to avoid hitting the database and thus eliminating the need for the painful session/state maintenance across multiple nodes? Your solution looks more like a DIY security solution to me, (please correct me if I'm wrong) and I would take major precautions in gambling with security-related functions of a framework.

P.S I am confused, please explain if I am wrong, I will gladly rather be corrected than make a possibly serious security mistake in one of my own applications.

Post reply on HN