Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails' CookieStore isn't broken

coffeepowered.net

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Rails' CookieStore isn't broken

#11

Post by thibaut_barrere »

jamescun wrote: post #3

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.

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

Re: Rails' CookieStore isn't broken

#12

Post by thibaut_barrere »

PLejeck wrote: post #7
joesb wrote: post #6

Earlier quoted context omitted.

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.

Re: Rails' CookieStore isn't broken

#13

Post by thibaut_barrere »

gnur wrote: post #4

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

Re: Rails' CookieStore isn't broken

#14

Post by RyanZAG »

PLejeck wrote: post #5

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

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

Re: Rails' CookieStore isn't broken

#15

Post by thibaut_barrere »

RyanZAG wrote: post #14
PLejeck wrote: post #5

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

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

Re: Rails' CookieStore isn't broken

#16

Post by progn »

PLejeck wrote: post #5

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.

Re: Rails' CookieStore isn't broken

#17

Post by 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.

Re: Rails' CookieStore isn't broken

#18

Post by sneak »

jamescun wrote: post #3

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.

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

Re: Rails' CookieStore isn't broken

#19

Post by etfb »

progn wrote: post #16
PLejeck wrote: post #5

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.

Re: Rails' CookieStore isn't broken

#20

Post by damncabbage »

sneak wrote: post #18
jamescun wrote: post #3

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.

> 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.
Post reply on HN