Re: Replay attacks with cookie session

Brad Ediger
2007-03-22T14:44:40Z

On Mar 22, 2007, at 8:52 AM, Alexey Verkhovsky wrote:

> On 3/22/07, Thijs van der Vossen <t.vandervossen@gmail.com> wrote:
> As long as you only use the session to maintain the id of the
> authenticated user and for flash messages there''s absolutely
nothing
> to worry about.
>
> Sure, but...
>
> Not everybody who develops web apps knows about "do not keep
> anything interesting in sessions" mantra, or agrees with it. At
> least a couple of times I had to explain it to people who were not
> clueless by any standard.
>
> It''s actually a rather arcane bit of knowledge, and if you
don''t
> have it, you may discover it the hard way, when it''s too late.
>
> Which makes session storage in cookies a good option, but perhaps
> not a good default (?)
>

For those just tuning in... :-)

This is the crux of the issue... of *course* it''s a terrible idea to
store sensitive or transient data in the session, but the question is
one of API design. Do we want the penalty for ignoring best practices
to be compromised security?

I happen to think it''s not a huge deal if we document properly. Web
developers need to understand all of the abstractions that Rails
builds on top of HTTP in order to build a secure web app. It''s the
same issue as people who throw things like

<input type="hidden" name="order[total_price]"
value="1250.00" />

into their online stores. If you don''t understand how the Web works,
you won''t build secure applications, no matter what framework you
work within. When PStore was the default, professional developers
understood what that meant and what freedoms and limitations it
afforded us. Now that CookieStore is the default session store, we
are responsible for understanding what that means.

Don''t get me wrong; the Rails team has a part to play in this --
documentation. To the extent that we give the impression that the
session is  a "big hash in the sky", people will put stupid things in
it.

After writing this and thinking about it, I realize that
authentication may be a problem. It makes me slightly uncomfortable
to hand the client a token saying, in effect, "I am logged in as Joe
User" with no qualifications, signed by the server. And that token
never expires on the server side -- you could come back 5 years later
and prove your identity. There is no way to selectively expire
sessions, e.g. based on time. You can change the secret, but that
expires all sessions including current ones. You can send the client
a new cookie that invalidates the old one -- but he can always ignore
it. He still has the valid authentication cookie from earlier, and it
will still work.

I would feel a lot better about it if it incorporated a nonce or some
other form of time-variant information. I can''t come up with an
attack other than the replay attack, but that "I am logged in as Joe
User" message seems too general to make me feel completely
comfortable about authentication via cookie sessions for the time being.

Brad