Rails core - Oct 2013 - Response to “Logout is broken by default in Ruby on Rails web applications”?

Hi,


Has there been any sort of “official” response to G.S. McNamara''s
recent
blog post “Logout is broken by default in Ruby on Rails web
applications<http://maverickblogging.com/logout-is-broken-by-default-ruby-on-rails-web-applications/>”
(also see the discussion on Hacker
News<https://news.ycombinator.com/item?id=6545923>
)?

The TL;DR is:

Ruby on Rails Web applications versions 2.0 through 4.0 are by default
> vulnerable to an oft-overlooked Web application security issue: Session 
> cookies are valid for life. The fix is to configure your Rails app to store
> most session information on the server side in the database.

Should this receive more attention in the Rails Guides, or maybe there 
should be a post on the Riding Rails blog explaining what the view of the 
Rails core team is on this matter (and the reasoning behind it)?

I know that there''s little that can be done about this on the code side
of
things without changing away from using CookieStore as the default session 
storage mechanism…


Best regards,
Matias Korhonen

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

(I believe) it already is:
http://guides.rubyonrails.org/security.html#session-fixation

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

On Oct 14, 2013, at 11:28 AM, Steve Klabnik wrote:
> (I believe) it already is:
http://guides.rubyonrails.org/security.html#session-fixation
The new article is about a different scenario - namely that the CookieStore
doesn''t include any kind of invalidation mechanism by default.

Short version:

1: attacker steals a session cookie from user Victim (NOTE: user is already
pwned at this point)

2: Victim logs out of the site

3: attacker uses the stolen cookie to continue acting as Victim

TBH, it''s a bug to be sure - but calling it "broken by
default" when the repro starts with "Step 1: the user is utterly
pwned" seems a bit hyperbolic.

Drink your SSL + Secure cookies, kids!

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Isn''t this a common problem with every other framework that uses
cookies
for sessions? I find it a bit hard on Rails given that point.

I remember doing some successful tests on Facebook (PHP) with FireSheep,
and I believe (please tell me if I''m wrong) that it gets fixed by using
SSL
to prevent the session data to be retrieved in the first place.


On Mon, Oct 14, 2013 at 5:20 PM, Matt Jones <al2o3cr@gmail.com> wrote:
>
> On Oct 14, 2013, at 11:28 AM, Steve Klabnik wrote:
>
> (I believe) it already is:
> http://guides.rubyonrails.org/security.html#session-fixation
>
>
> The new article is about a different scenario - namely that the
> CookieStore doesn''t include any kind of invalidation mechanism by
default.
>
> Short version:
>
> 1: attacker steals a session cookie from user Victim (NOTE: user is
> already pwned at this point)
>
> 2: Victim logs out of the site
>
> 3: attacker uses the stolen cookie to continue acting as Victim
>
> TBH, it''s a bug to be sure - but calling it "broken by
default" when the
> repro starts with "Step 1: the user is utterly pwned" seems a bit
> hyperbolic.
>
> Drink your SSL + Secure cookies, kids!
>
> --Matt Jones
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

On 14/10/2013, at 11:13 PM, Matias Korhonen <korhonen.matt@gmail.com>
wrote:
> Hi,
> 
> 
> Has there been any sort of “official” response to G.S. McNamara''s
recent blog post “Logout is broken by default in Ruby on Rails web applications”
(also see the discussion on Hacker News)?
> 
> The TL;DR is:
> 
> Ruby on Rails Web applications versions 2.0 through 4.0 are by default
vulnerable to an oft-overlooked Web application security issue: Session cookies
are valid for life. The fix is to configure your Rails app to store most session
information on the server side in the database.
> 
> Should this receive more attention in the Rails Guides, or maybe there
should be a post on the Riding Rails blog explaining what the view of the Rails
core team is on this matter (and the reasoning behind it)?
G.S wrote to the security list with this shortly after publishing his blog post,
I responded to him there but can do it here too.  The behaviour mentioned is a
limitation of the underlying storage mechanism that the CookieStore uses,
there''s simply no way to do server side invalidation when
there''s no server side storage.  Most applications have the same or
similar  issues with values stored in signed cookies such as remember-me tokens.

There are certainly applications where the lack of server-side invalidation is
severely problematic, which is why we ship with several alternative session
stores.  However it''s true that we could probably do a better job of
documenting those limitations in the guides and the api documentation.
> I know that there''s little that can be done about this on the code
side of things without changing away from using CookieStore as the default
session storage mechanism…
Switching the default store to something else is definitely something we could
consider, however each of the alternative stores has their own set of downsides.
The AR Store generates huge tables and the memcache store requires a separate
long-running process.

In terms of changes to the CookieStore we could include expiry information in
the payload and refuse to accept cookies which have expired.   However this will
have other issues as people''s sessions which previously never expired
will suddenly start expiring.

So I guess in short, yes we should improve the documentation  to make the risk
clearer, we should also try and expose a time limit that users can use to work
around the issue. But if this issue is important for your application, you
should switch your session store to one of the alternative stores as
that''s the simplest and most reliable way to avoid the issue entirely.

--
Cheers,

Koz