Re: Replay attacks with cookie session

Jeremy Kemper
2007-03-21T21:26:58Z

On 3/21/07, S. Robert James <srobertjames@gmail.com>
wrote:
> IMO, we need to rethink moving to cookie sessions by default, then -
> if a core member hadn''t thought about, what can we expect from
> beginners? Last thing we need is a reputation for being weak in
> security.

I think that''s a bit sensational.  The cookie store has gone through a
couple of evolutionary steps already and is ready for more, if need
be.


> Before everyone responds: "It will help performance, and good
> developers don''t store volatile data in the session, anyway!"
I''ll say
> that we''ve seen lots of companies (who won''t be named)
sacrifice
> security in order to gain out of the box performance or ease of use -
> and it comes back to haunt them.  Secure by default, and let the
> advanced users make it less secure to improve performance - not the
> other way around.

Let''s see a brainstorm of solutions and other potential
vulnerabilities.


> > > This is normally solved using something called nonce - each
signing
> > > includes a once only code, and the signer keeps track of all of
the
> > > codes, and rejects any message with the code repeated.
>
> > This sounds like something you could perform at the application level.
> I don''t think so - as long as step 2 (in my example) goes to one
> Mongrel, and step 4 goes to another, the attack succeeds.  I can try
> repeatedly with a script until this happens.  The only way to protect
> is to use a shared backend like the DB or DRB - but then you''ve
lost
> the point of cookie sessions.

To some degree. I''m sure there''s more to this, though.
I''m not a crypto expert.

jeremy