

Rails' CookieStore isn't broken - thibaut_barrere
https://www.coffeepowered.net/2013/09/26/rails-session-cookies/

======
jamescun
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.

~~~
sneak
> 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?!

~~~
damncabbage
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.

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

------
jrochkind1
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?)

~~~
cheald
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.

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

------
PLejeck
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

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

~~~
PLejeck
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.

~~~
thibaut_barrere
Exactly - use force_ssl true in the case of Rails.

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

~~~
thibaut_barrere
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.

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

~~~
thibaut_barrere
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...](http://guides.rubyonrails.org/action_controller_overview.html#session)

~~~
InAnEmergency
It's also mentioned in the security guide:
[http://guides.rubyonrails.org/security.html#session-
storage](http://guides.rubyonrails.org/security.html#session-storage)

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

~~~
tptacek
Wasn't that Vizzini?

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

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

------
eric970
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?

