Rails' CookieStore isn't broken | Hacker News Reader

Rails' CookieStore isn't broken

coffeepowered.net

I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using something like Firesheep or as simple as forgetting to logout of a public terminal. You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.

I recognize this fight. Person A has a system, person B finds a problem in it. Now, is it a "real" problem?

Emotions run high, on both sides, and I've been on both sides of it at various points in my life. I recognize the patterns of the bad arguments made by both sides (by A: "of course you don't do that," "this requires something else bad to happen," "that's a problem with bad coders", "you are an idiot"; and by B: "every potential issue is worth full attention," "you should always stop your developers from breaking things," "you can't fix things with obscurity!!!1," "you'll be sorry", "you are an idiot.").

Just to clarify, in case this is needed: I totally agree. Just posted that to bring fuel to the discussion.

My hope is that expiration will be soon baked-in (or easier to bake in), after reading https://github.com/rails/rails/pull/11168

> You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.

Completely agreed - that's the gist of the DB bits there. Right now, you can terminate a compromised AR-backed session by logging out, but if you lose that session ID, then you have no control over the compromised session. If someone jacks your SID while you're on a public terminal, using ARStore alone isn't going to save you.

> Especially when cookies are easily stolen using something like Firesheep

Who in late 2013 (with enough clue to care about this issue) is still using non-secure-flag cookies for anything even remotely important?!

As far as I'm Rails doesn't use secure-flag cookies by default; you need to have something like this in config/initializers/session_store.rb:

  local_env = !(Rails.env.test? || Rails.env.development?)
  MyApp::Application.config.session_store(:cookie_store, {
    key:    '_my_app_session',
    secure: local_env, # ... or just true
  })

Yes, somebody who has gone looking for this can find it, but I'd argue that Rails should at least give you the secure: ... option in a comment block. Anything less is just inviting people to get bitten by the lack of it.

You can set config.force_ssl = true to easily enable secure session cookies and strict transport security amongst other things.

If you're going to store info about sessions in the database and thus have to query the database on every request to make sure the cookie-delivered session is okay... why wouldn't you just use the ActiveRecord session store instead of the cookie store?

What do you gain by using the cookie store with this database component, over just using the active record store to begin with? (The ActiveRecord store used to be the default back in... Rails 2.0?)

Hi, author here. That's a fair question! The database code I presented there isn't just to database-ify sessions, but to provide user->sessions association, which none of the existing stores do. That technique is applicable to AR stores as well as others, and essentially provides users with control over their list of purportedly active sessions. The first solution I presented was just a simple server-enforced timeout on sessions which doesn't require any DB work.

I think it's still worthwhile to use CookieStore even if you're going to go to the DB, because:

1. You only do DB round-trips for cookies that contain a valid user ID, and you're going to be pulling that user record anyway, so the net effect is a few extra bytes over the wire on DB work you were going to be doing anyway. Critically, this means that anonymous users aren't going to be generating sessions that you have to store and validate on every page with a form (as forms use csrf_token which generates a session!)

2. Additionally, less data over the wire between the app and DB. You're going to have a small list of active sessions; you could enforce that as a to a small number to ensure it stays small.

3. You retain CookieStore's invulnerability to session fixation.

4. No sweeping!

You can still put most of the work on the client, and only keep the verification bits on the server. Of course, the same technique is applicable to DB-backed stores as well, as a means to provide a mechanism for users to manage their sessions.

The problem is not CookieStore itself but the fact that you need to know the caveats if you expect to use it properly. That alone makes it a bad default setting for a framework that favors convention over configuration.

I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS.

Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO

> I always assumed cryptography is slower than IO

Cryptography is a CPU-bound operation that often has specialized hardware support. Here's a rule of thumb: in modern computing, IO incurs a greater cost than pretty much anything you can do locally on-CPU. IO is incredibly expensive: cryptography, not so much. If you pipeline your crypto operations and disk fetches, you won't increase response latency at all.

Ruby has a reputation for slowness ([citation needed]?) so is the cryptographic stuff implemented in the language itself or via C-or-equivalent foreign library? I could understand the "too slow, must avoid" kneejerk reaction if it's all in Ruby, even if the reputation is no longer deserved. Human nature.

Cryptography in Ruby uses OpenSSL wrapper, so it's essentially C.

Running over HTTPS is not enough, stripping SSL when you can MITM or alter traffic is incredible easy and adds no real complexity. You must both force https and have HSTS enabled at a minimum [1]. Some javascript to ensure that the page being displayed is running over https for first-time users is also a good bet (but can be circumvented).

[1] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

In the case of Rails, the force_ssl option enables HSTS.

Useful link: http://jamescrisp.org/2013/08/04/moving-to-https-rails-force...

What do you mean? Rails support running over HTTPS. Or are you suggesting that Rails never run over HTTP only?

I'm suggesting that site operators need to use HTTPS. It doesn't matter if you use Rails, PHP, Node.js, whatever. USE HTTPS. NEVER USE HTTP.

It's as simple as that. Never assume that anything transmitted over HTTP is safe, because that assumption will come back to bite you.

Exactly - use force_ssl true in the case of Rails.

do you ever get a headache from sitting in this echo chamber all day?

I'm not sure to understand (I see that you're likely using irony, but I'm not a native english speaker).

Are you suggesting not using SSL?

If not, can you clarify your point?

Thanks.

I think he means getting devs who deploy Rails apps to start using HTTPS for their app, rather than there being a deficiency in the framework.

The CookieStore isn't broken but you do need to add code to fix the issue? I have no experience with Rails but I really hadn't expected that sessions would be client-side only.

FWIW, the fact that the default session store is client-side only is mentioned in the overview for beginners:

http://guides.rubyonrails.org/action_controller_overview.htm...

It's also mentioned in the security guide: http://guides.rubyonrails.org/security.html#session-storage

Storing IDs in session cookies is not something the Rails framework introduced. Smh. It's easier to blame someone else's code though.

I have to declare Inigo Montoya on the use of the word "trivially" in that article, though I see from a comment here that someone's already issued a patch that I presume will get included in the next version, so perhaps it will become trivial shortly.

Wasn't that Vizzini?

It was Vizzini who kept using that word, and Montoya who did not think it meant what he (Vizzini) thought it meant.

D'oh! I was thinking it was Westley who pointed that out. I lose 1000 nerd credibility points.

So the provided solution is, essentially, to store a list of active user sessions in the database and use that as a reference during authentication?

Reply on news.ycombinator.com